From owner-multi6@ops.ietf.org Tue Jun 1 08:15:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22330 for ; Tue, 1 Jun 2004 08:15:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BV86v-000PFS-05 for multi6-data@psg.com; Tue, 01 Jun 2004 12:11:17 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BV86t-000PF3-P3 for multi6@ops.ietf.org; Tue, 01 Jun 2004 12:11:15 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i51CBElg074146 for ; Tue, 1 Jun 2004 12:11:14 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i51CBDCj131844 for ; Tue, 1 Jun 2004 14:11:14 +0200 Received: from zurich.ibm.com (sig-9-145-139-176.de.ibm.com [9.145.139.176]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA24824 for ; Tue, 1 Jun 2004 14:11:13 +0200 Message-ID: <40BC7262.9040206@zurich.ibm.com> Date: Tue, 01 Jun 2004 14:11:14 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: More scribe volunteers needed for interim meeting Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, For the interim MULTI6 meeting on June 14, we still need more volunteers to act as jabber scribes. We will also need a scribe for the regular minutes. Thanks Brian co-chair From owner-multi6@ops.ietf.org Tue Jun 1 09:21:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27483 for ; Tue, 1 Jun 2004 09:21:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BV9AA-000ADA-ME for multi6-data@psg.com; Tue, 01 Jun 2004 13:18:42 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BV9A9-000ACr-K5 for multi6@ops.ietf.org; Tue, 01 Jun 2004 13:18:41 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i51DIdo07798; Tue, 1 Jun 2004 16:18:39 +0300 (EET DST) X-Scanned: Tue, 1 Jun 2004 16:17:43 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i51DHhXu032185; Tue, 1 Jun 2004 16:17:43 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00EDE5MW; Tue, 01 Jun 2004 16:17:40 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i51DHdH10582; Tue, 1 Jun 2004 16:17:39 +0300 (EET DST) Received: from nam.ext.nokia.com ([192.100.121.78]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Jun 2004 16:13:31 +0300 Message-ID: <3623475.1086095395735.JavaMail.decuma@nam.ext.nokia.com> Date: Tue, 1 Jun 2004 16:09:55 +0300 (EEST) From: John Loughney To: brc@zurich.ibm.com, john.loughney@nokia.com, multi6@ops.ietf.org Subject: RE: More scribe volunteers needed for interim meeting Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8_16328229.1086095395726" X-OriginalArrivalTime: 01 Jun 2004 13:13:31.0856 (UTC) FILETIME=[3C9CAD00:01C447DA] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk ------=_Part_8_16328229.1086095395726 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 7bit Brian, I can be a secondary jabber subscriber. I may want to be active in the meeting, so I may have some gaps in the transmission. John ))) Message sent using Nokia Access Mobilizer ((( --- Original Message --- From: ext Brian E Carpenter To: Multi6 Date: Tue Jun 01 15:11:14 EEST 2004 Subject: More scribe volunteers needed for interim meeting Hi, For the interim MULTI6 meeting on June 14, we still need more volunteers to act as jabber scribes. We will also need a scribe for the regular minutes. Thanks Brian co-chair ------=_Part_8_16328229.1086095395726-- From owner-multi6@ops.ietf.org Tue Jun 1 10:51:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10371 for ; Tue, 1 Jun 2004 10:51:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVAaO-000O0W-0s for multi6-data@psg.com; Tue, 01 Jun 2004 14:49:52 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVAaJ-000NzO-0m for multi6@ops.ietf.org; Tue, 01 Jun 2004 14:49:47 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i51EncfV054864; Tue, 1 Jun 2004 14:49:38 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i51Enbhf281108; Tue, 1 Jun 2004 16:49:37 +0200 Received: from zurich.ibm.com (sig-9-145-139-176.de.ibm.com [9.145.139.176]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA52320; Tue, 1 Jun 2004 16:49:36 +0200 Message-ID: <40BC977F.20500@zurich.ibm.com> Date: Tue, 01 Jun 2004 16:49:35 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: John Loughney CC: multi6@ops.ietf.org Subject: Re: More scribe volunteers needed for interim meeting References: <3623475.1086095395735.JavaMail.decuma@nam.ext.nokia.com> In-Reply-To: <3623475.1086095395735.JavaMail.decuma@nam.ext.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks John! That's exactly why we need several scribes... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM John Loughney wrote: > Brian, > > I can be a secondary jabber subscriber. I may want to be active in the > meeting, so I may have some gaps in the transmission. > > John > > > > ))) Message sent using Nokia Access Mobilizer ((( > > --- Original Message --- > From: ext Brian E Carpenter > To: Multi6 > Date: Tue Jun 01 15:11:14 EEST 2004 > Subject: More scribe volunteers needed for interim meeting > > > Hi, > > For the interim MULTI6 meeting on June 14, we still need > more volunteers to act as jabber scribes. > > We will also need a scribe for the regular minutes. > > Thanks > > Brian > co-chair > > > > > From owner-multi6@ops.ietf.org Fri Jun 4 17:24:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14368 for ; Fri, 4 Jun 2004 17:24:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWM8W-000BDV-AB for multi6-data@psg.com; Fri, 04 Jun 2004 21:22:00 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWM8V-000BD7-0a for multi6@ops.ietf.org; Fri, 04 Jun 2004 21:21:59 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i54LLrcH028046 for ; Fri, 4 Jun 2004 14:21:58 -0700 (PDT) Received: from blixten (bobo.SFBay.Sun.COM [129.146.89.81]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i54LLqQ11856 for ; Fri, 4 Jun 2004 23:21:52 +0200 (MEST) Date: Fri, 4 Jun 2004 14:21:48 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: I-D ACTION:draft-nordmark-multi6-threats-01.txt (Fwd) To: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <200406042015.QAA07129@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk The draft contains a changelog in appendix A. >----------------Begin Forwarded Message----------------< Date: Fri, 04 Jun 2004 16:15:45 -0400 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nordmark-multi6-threats-01.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Threats relating to IPv6 multihoming solutions Author(s) : E. Nordmark, T. Li Filename : draft-nordmark-multi6-threats-01.txt Pages : 25 Date : 2004-6-4 This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses. The intent is to look at how IPv6 multihoming solutions might make the Internet less secure than the current Internet, without studying any proposed solution but instead looking at threats that are inherent in the problem itself. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nordmark-multi6-threats-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-nordmark-multi6-threats-01.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-nordmark-multi6-threats-01.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. >----------------End Forwarded Message----------------< From owner-multi6@ops.ietf.org Sun Jun 6 00:03:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24711 for ; Sun, 6 Jun 2004 00:03:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWopO-0005gD-0O for multi6-data@psg.com; Sun, 06 Jun 2004 04:00:10 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWopN-0005fp-7k for multi6@ops.ietf.org; Sun, 06 Jun 2004 04:00:09 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id B3C702BD for ; Sun, 6 Jun 2004 00:00:08 -0400 (EDT) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 06 Jun 2004 00:00:08 -0400 Message-Id: <20040606040008.B3C702BD@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 16.67% | 1 | 69.35% | 35115 | kurtis@kurtis.pp.se 33.33% | 2 | 10.49% | 5310 | brc@zurich.ibm.com 16.67% | 1 | 8.92% | 4516 | erik.nordmark@sun.com 16.67% | 1 | 6.40% | 3243 | john.loughney@nokia.com 16.67% | 1 | 4.84% | 2450 | sra@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 6 |100.00% | 50634 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Sun Jun 6 04:42:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18309 for ; Sun, 6 Jun 2004 04:42:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWtCn-000EQE-PP for multi6-data@psg.com; Sun, 06 Jun 2004 08:40:37 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWtCd-000EP8-U5 for multi6@ops.ietf.org; Sun, 06 Jun 2004 08:40:28 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i568eQfV086872 for ; Sun, 6 Jun 2004 08:40:26 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i568eQA0222306 for ; Sun, 6 Jun 2004 10:40:26 +0200 Received: from zurich.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id KAA32894 for ; Sun, 6 Jun 2004 10:40:25 +0200 Message-ID: <40C2D874.1020101@zurich.ibm.com> Date: Sun, 06 Jun 2004 10:40:20 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: I-D ACTION:draft-nordmark-multi6-threats-01.txt (Fwd) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit And this is the version we will review at the interim meeting on June 14, so please read it before then! Brian co-chair Erik Nordmark wrote: > The draft contains a changelog in appendix A. > > >>----------------Begin Forwarded Message----------------< > > > Date: Fri, 04 Jun 2004 16:15:45 -0400 > From: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-nordmark-multi6-threats-01.txt > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Threats relating to IPv6 multihoming solutions > Author(s) : E. Nordmark, T. Li > Filename : draft-nordmark-multi6-threats-01.txt > Pages : 25 > Date : 2004-6-4 > > This document lists security threats related to IPv6 multihoming. > Multihoming can introduce new opportunities to redirect packets to > different, unintended IP addresses. > > The intent is to look at how IPv6 multihoming solutions might make > the Internet less secure than the current Internet, without studying > any proposed solution but instead looking at threats that are > inherent in the problem itself. The threats in this document build > upon the threats discovered and discussed as part of the Mobile IPv6 > work. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nordmark-multi6-threats-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce to change your > subscription settings. > > > 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-nordmark-multi6-threats-01.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-nordmark-multi6-threats-01.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. > >>----------------End Forwarded Message----------------< > > > From owner-multi6@ops.ietf.org Mon Jun 7 11:10:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22627 for ; Mon, 7 Jun 2004 11:10:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXLj2-000Oy9-Dv for multi6-data@psg.com; Mon, 07 Jun 2004 15:07:48 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXLj0-000Oxo-Gb for multi6@ops.ietf.org; Mon, 07 Jun 2004 15:07:46 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i57F7jfV091540; Mon, 7 Jun 2004 15:07:45 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i57F7jur270514; Mon, 7 Jun 2004 17:07:45 +0200 Received: from zurich.ibm.com (sig-9-145-227-158.de.ibm.com [9.145.227.158]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA63706; Mon, 7 Jun 2004 17:07:44 +0200 Message-ID: <40C484BF.2080603@zurich.ibm.com> Date: Mon, 07 Jun 2004 17:07:43 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Erik Nordmark , Multi6 Subject: Comments on draft-nordmark-multi6-threats-01 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Substantive comments: > 1.1. Assumptions ... > > This document doesn't assume that the application protocols are > protected by strong security today or in the future. However, it is > still useful to assume that the application protocols which care > about integrity and/or confidentiality apply the relevant end-to-end > security measures, such as IPsec or TLS. That's a narrow view of e2e security; I would add "and/or applications level security." > 2. TERMINOLOGY ... > > interface - a node's attachment to a link. Is this intended to include virtual or pseudo interfaces such as tunnel end points? > > address - an IP layer name that contains both topological > significance and acts as a unique identifier for an > interface. There may be multiple addresses per interface. > > locator - an IP layer topological name for an interface or a > set of interfaces. There may be multiple locators per interface. > identifier - an IP layer identifier for an IP layer endpoint > (stack name in [NSRG]). The transport endpoint is a > function of the transport protocol and would > typically include the IP identifier plus a port > number. Do we believe there may be multiple identifiers per interface or per host? > 3.1. Application Assumptions ... > The second class of applications use existing IP source addresses > from outside of their immediate local site as a means of > authentication without any form of verification. Today, with source > IP address spoofing and TCP sequence number guessing as rampant > attacks, such applications are effectively opening themselves for > public connectivity and are reliant on other systems, such as > firewalls, for overall security. We do not consider this class of > systems in this document. ...because they are in any case fully open to all forms of network layer spoofing. > The third class of applications receive existing IP source addresses, > but attempt some verification using the DNS, effectively using the > FQDN for access control. (This is typically done by performing a > reverse lookup from the IP address followed by a forward lookup and > verifying that the IP address matches one of the addresses returned > from the forward lookup.) These applications are already subject to > a number of attacks using techniques like source address spoofing and > TCP sequence number guessing since an attacker, knowing this is the > case, can simply create a DoS attack using a forged source address > that has authentic DNS records. In general this class of > applications is strongly discouraged, but it is probably important > that a multihoming solution doesn't introduce any new and easier ways > to perform such attacks. But do we desire to make reverse lookup checks for multihomed sites succeed, to avoid multihoming failures for hosts using the broken technique? > Finally, the fifth class of applications use cryptographic security > techniques but without strong identity (such as opportunistic IPsec). > Thus data integrity with or without confidentiality is provided when > communicating with an unknown/unauthenticated principal. Just like > the first category above such applications can't perform access > control since they do not know the identity of the peer. This is true *at network level* but they may well have applications level strong identity and that may be necessary and sufficient. Nits: > 2. TERMINOLOGY ... > FQDN - Fully Qualified Domain Name I would add a reference to RFC 1594, which seems to be the only place that FQDN is defined > 3.1. Application Assumptions > > In the Internet today, the initiating part of applications either > starts with a FQDN, which it looks up in the DNS, or already has an > IP address from somewhere. For the FQDN to IP address lookup the > application effectively places trust in the DNS. Once it has the IP > address, the application places trust in the routing system > delivering packets to that address. Applications that use security > mechanisms, such as IPsec or TLS, with mutual authentication have the > ability to "bind" the FQDN to the cryptographic keying material thus --------------------------------------------------------------------^^ missing punctuation > compromising the DNS and/or the routing system can at worst cause the > packets to be dropped or delivered to an entity which does not posses > the keying material. ... > 5. GRANULARITY OF REDIRECTION > > Different multihoming solutions might approach the problem at > different layers in the protocol stack. For instance, there has been ------------------------------------------------------------------^^^ grammar > proposals on a shim layer inside IP as well as transport layer ---------------^^ grammar > approaches. Brian From owner-multi6@ops.ietf.org Mon Jun 7 11:19:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22996 for ; Mon, 7 Jun 2004 11:19:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXLta-0000iz-Np for multi6-data@psg.com; Mon, 07 Jun 2004 15:18:42 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXLtZ-0000id-A7 for multi6@ops.ietf.org; Mon, 07 Jun 2004 15:18:41 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i57FIdAN065334 for ; Mon, 7 Jun 2004 15:18:40 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i57FIdol146810 for ; Mon, 7 Jun 2004 17:18:39 +0200 Received: from zurich.ibm.com (sig-9-145-227-158.de.ibm.com [9.145.227.158]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA25878 for ; Mon, 7 Jun 2004 17:18:39 +0200 Message-ID: <40C4874F.7030901@zurich.ibm.com> Date: Mon, 07 Jun 2004 17:18:39 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Final reminder about interim meeting on June 14 Content-Type: multipart/mixed; boundary="------------070908050005070509070208" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------070908050005070509070208 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Here is a final reminder about the meeting on June 14. For jabber fans, we are hoping to have scribes operating. We may well re-time the agenda on site, and please remember that you are expected to read the three drafts beforehand. Brian and Kurtis co-chairs --------------070908050005070509070208 Content-Type: text/plain; name="interim-agenda.txt" Content-Disposition: inline; filename="interim-agenda.txt" Content-Transfer-Encoding: 7bit Updated announcement and agenda for MULTI6 WG interim meeting ============================================================= Date: Monday June 14, 2004 Time: 09:00 - 17:00 PDT Place: Loews Beach Hotel, Santa Monica, CA, USA This is the same location as the North American IPv6 Summit; see http://www.usipv6.com/ for full logistics and hotel discount code. (Of course, you may also wish to register for the Summit.) There are many other hotels and plenty of restaurants nearby. The room will hold about 100 people; The informal count of attendees is about 30. Breakfast and lunch NOT provided. Coffee breaks planned at 10:00 and 15:00 PDT, lunch break around noon. An informal "Bar BOF" will be held in the late afternoon of Sunday June 13 to prepare for the main meeting. Location: somewhere in Loews Hotel. The goal of the meeting is to reach common ground on architectural analysis and on the impact of various classes of solution. It is *not* to discuss solutions in detail or to choose one of them. Draft agenda (comments welcome). 1. IPR reminder, logistics, agenda bashing (co-chairs, 10 min.) 2. Charter review (co-chairs, 5 min.) http://www.ietf.org/html.charters/multi6-charter.html 3. Review "Things to think about" draft (Eliot Lear, 45 min.) http://www.ietf.org/internet-drafts/draft-lear-multi6-things-to-think-about-02.txt 4. Review threats draft (Erik Nordmark, 45 min.) http://www.ietf.org/internet-drafts/draft-nordmark-multi6-threats-01.txt 5. Review + discuss future Architecture draft (Geoff Huston by phone, co-chairs, 2 hours) http://www.ietf.org/internet-drafts/draft-huston-multi6-architectures-00.txt 6. Open discussion on the impact of various categories of solutions (co-chairs, 1 hour) 7. Conclusions of meeting and where to move from here. Brian Carpenter & Kurt Erik Lindqvist, multi6 co-chairs --------------070908050005070509070208-- From owner-multi6@ops.ietf.org Mon Jun 7 19:17:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02144 for ; Mon, 7 Jun 2004 19:17:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXTKY-0000Tg-33 for multi6-data@psg.com; Mon, 07 Jun 2004 23:15:02 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXTKW-0000Sh-K4 for multi6@ops.ietf.org; Mon, 07 Jun 2004 23:15:00 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i57NEwNf008344; Mon, 7 Jun 2004 16:14:59 -0700 (PDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i57NEuQ10962; Tue, 8 Jun 2004 01:14:56 +0200 (MEST) Date: Mon, 7 Jun 2004 16:14:52 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on draft-nordmark-multi6-threats-01 To: Brian E Carpenter Cc: Erik Nordmark , Multi6 In-Reply-To: "Your message with ID" <40C484BF.2080603@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Thanks for the comments. A few followup questions below. > > This document doesn't assume that the application protocols are > > protected by strong security today or in the future. However, it is > > still useful to assume that the application protocols which care > > about integrity and/or confidentiality apply the relevant end-to-end > > security measures, such as IPsec or TLS. > > That's a narrow view of e2e security; I would add "and/or applications > level security." I thought "such as" implied that they were examples and not a complete list. I can rephrase this to be more inclusive though. > > interface - a node's attachment to a link. > > Is this intended to include virtual or pseudo interfaces > such as tunnel end points? Include. I'll copy the rfc 2460 definition of "link" into the draft to make this more clear since it explicitly talks about tunnels. > > > > address - an IP layer name that contains both topological > > significance and acts as a unique identifier for an > > interface. > > There may be multiple addresses per interface. Added. > > > > locator - an IP layer topological name for an interface or a > > set of interfaces. > > There may be multiple locators per interface. Added. > > identifier - an IP layer identifier for an IP layer endpoint > > (stack name in [NSRG]). The transport endpoint is a > > function of the transport protocol and would > > typically include the IP identifier plus a port > > number. > > Do we believe there may be multiple identifiers per interface or per host? I think there is utility to have multiple identifiers per stack/host. For example due to privacy concerns, when using different (and changing over time) identifiers for certain outbound connections while still having one (or more) identifiers for inbound communication. Should we make it explicit that the identifiers are not (necessarily) tied to an interface? > > 3.1. Application Assumptions > ... > > The second class of applications use existing IP source addresses > > from outside of their immediate local site as a means of > > authentication without any form of verification. Today, with source > > IP address spoofing and TCP sequence number guessing as rampant > > attacks, such applications are effectively opening themselves for > > public connectivity and are reliant on other systems, such as > > firewalls, for overall security. We do not consider this class of > > systems in this document. > > ...because they are in any case fully open to all forms of network > layer spoofing. Added. > > The third class of applications receive existing IP source addresses, > > but attempt some verification using the DNS, effectively using the > > FQDN for access control. (This is typically done by performing a > > reverse lookup from the IP address followed by a forward lookup and > > verifying that the IP address matches one of the addresses returned > > from the forward lookup.) These applications are already subject to > > a number of attacks using techniques like source address spoofing and > > TCP sequence number guessing since an attacker, knowing this is the > > case, can simply create a DoS attack using a forged source address > > that has authentic DNS records. In general this class of > > applications is strongly discouraged, but it is probably important > > that a multihoming solution doesn't introduce any new and easier ways > > to perform such attacks. > > But do we desire to make reverse lookup checks for multihomed sites > succeed, to avoid multihoming failures for hosts using the broken > technique? For "application compatibility" I think we want to ensure that the reverse+forward lookups applications do today don't work any less. But that isn't driven by the threats - it's driven by trying for as much compatibility as possible. Should the threats document say something about this? > > > Finally, the fifth class of applications use cryptographic security > > techniques but without strong identity (such as opportunistic IPsec). > > Thus data integrity with or without confidentiality is provided when > > communicating with an unknown/unauthenticated principal. Just like > > the first category above such applications can't perform access > > control since they do not know the identity of the peer. > > This is true *at network level* but they may well have applications > level strong identity and that may be necessary and sufficient. Correct. I'll add that. Suggested new text for the last sentence: Just like the first category above such applications can't perform access control based on network layer information since they do not know the identity of the peer. However, they might perform access control using higher-level notions of identity. > > FQDN - Fully Qualified Domain Name > > I would add a reference to RFC 1594, which seems to be the only place > that FQDN is defined Or FYI18/RFC1983. Erik From owner-multi6@ops.ietf.org Tue Jun 8 06:36:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17165 for ; Tue, 8 Jun 2004 06:36:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXdtw-0008Fy-31 for multi6-data@psg.com; Tue, 08 Jun 2004 10:32:16 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXdtu-0008Ac-PB for multi6@ops.ietf.org; Tue, 08 Jun 2004 10:32:14 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58AWCx27151; Tue, 8 Jun 2004 13:32:12 +0300 (EET DST) X-Scanned: Tue, 8 Jun 2004 13:31:46 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i58AVk1J030806; Tue, 8 Jun 2004 13:31:46 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00PW6f1c; Tue, 08 Jun 2004 13:31:45 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58AViH28225; Tue, 8 Jun 2004 13:31:44 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Jun 2004 13:31:45 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Final reminder about interim meeting on June 14 Date: Tue, 8 Jun 2004 13:31:44 +0300 Message-ID: Thread-Topic: Final reminder about interim meeting on June 14 Thread-Index: AcRMoz7xw2hsEzUdQi+ynsUqANqkIQAoFaGg From: To: , X-OriginalArrivalTime: 08 Jun 2004 10:31:45.0385 (UTC) FILETIME=[CBFEFD90:01C44D43] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Brian, > We may well re-time the agenda on site, and please remember > that you are expected to read the three drafts beforehand. The following draft is no longer available: draft-lear-multi6-things-to-think-about-02.txt I assume you mean ver 3: http://www.ietf.org/internet-drafts/draft-lear-multi6-things-to-think-abo= ut-03.txt thanks, John From owner-multi6@ops.ietf.org Tue Jun 8 09:18:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24972 for ; Tue, 8 Jun 2004 09:18:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXgSw-000EU9-A9 for multi6-data@psg.com; Tue, 08 Jun 2004 13:16:34 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXgSu-000ETn-J5 for multi6@ops.ietf.org; Tue, 08 Jun 2004 13:16:32 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i58DG4lg114590; Tue, 8 Jun 2004 13:16:04 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i58DG48u188596; Tue, 8 Jun 2004 15:16:04 +0200 Received: from zurich.ibm.com (dyn-9-13-126-72.ge.ch.ibm.com [9.13.126.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA46076; Tue, 8 Jun 2004 15:16:03 +0200 Message-ID: <40C5BC13.3000407@zurich.ibm.com> Date: Tue, 08 Jun 2004 15:16:03 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: john.loughney@nokia.com CC: multi6@ops.ietf.org Subject: Re: Final reminder about interim meeting on June 14 References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------080403090408020800060603" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------080403090408020800060603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Apologies for that error. I've attached an updated agenda with the correct reference. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM john.loughney@nokia.com wrote: > Brian, > > >>We may well re-time the agenda on site, and please remember >>that you are expected to read the three drafts beforehand. > > > The following draft is no longer available: > > draft-lear-multi6-things-to-think-about-02.txt > > I assume you mean ver 3: > > http://www.ietf.org/internet-drafts/draft-lear-multi6-things-to-think-about-03.txt > > thanks, > John > --------------080403090408020800060603 Content-Type: text/plain; name="interim-agenda.txt" Content-Disposition: inline; filename="interim-agenda.txt" Content-Transfer-Encoding: 7bit Updated announcement and agenda for MULTI6 WG interim meeting ============================================================= Date: Monday June 14, 2004 Time: 09:00 - 17:00 PDT Place: Loews Beach Hotel, Santa Monica, CA, USA This is the same location as the North American IPv6 Summit; see http://www.usipv6.com/ for full logistics and hotel discount code. (Of course, you may also wish to register for the Summit.) There are many other hotels and plenty of restaurants nearby. The room will hold about 100 people; The informal count of attendees is about 30. Breakfast and lunch NOT provided. Coffee breaks planned at 10:00 and 15:00 PDT, lunch break around noon. An informal "Bar BOF" will be held in the late afternoon of Sunday June 13 to prepare for the main meeting. Location: somewhere in Loews Hotel. The goal of the meeting is to reach common ground on architectural analysis and on the impact of various classes of solution. It is *not* to discuss solutions in detail or to choose one of them. Draft agenda (comments welcome). 1. IPR reminder, logistics, agenda bashing (co-chairs, 10 min.) 2. Charter review (co-chairs, 5 min.) http://www.ietf.org/html.charters/multi6-charter.html 3. Review "Things to think about" draft (Eliot Lear, 45 min.) http://www.ietf.org/internet-drafts/draft-lear-multi6-things-to-think-about-03.txt 4. Review threats draft (Erik Nordmark, 45 min.) http://www.ietf.org/internet-drafts/draft-nordmark-multi6-threats-01.txt 5. Review + discuss future Architecture draft (Geoff Huston by phone, co-chairs, 2 hours) http://www.ietf.org/internet-drafts/draft-huston-multi6-architectures-00.txt 6. Open discussion on the impact of various categories of solutions (co-chairs, 1 hour) 7. Conclusions of meeting and where to move from here. Brian Carpenter & Kurt Erik Lindqvist, multi6 co-chairs --------------080403090408020800060603-- From owner-multi6@ops.ietf.org Tue Jun 8 09:26:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25603 for ; Tue, 8 Jun 2004 09:26:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXgbG-000GQM-O5 for multi6-data@psg.com; Tue, 08 Jun 2004 13:25:10 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXgbF-000GQ6-5D for multi6@ops.ietf.org; Tue, 08 Jun 2004 13:25:09 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i58DP8lg082006; Tue, 8 Jun 2004 13:25:08 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i58DP78u170188; Tue, 8 Jun 2004 15:25:07 +0200 Received: from zurich.ibm.com (dyn-9-13-126-72.ge.ch.ibm.com [9.13.126.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA34718; Tue, 8 Jun 2004 15:25:07 +0200 Message-ID: <40C5BE33.6020801@zurich.ibm.com> Date: Tue, 08 Jun 2004 15:25:07 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Erik Nordmark CC: Multi6 Subject: Re: Comments on draft-nordmark-multi6-threats-01 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, Thanks. My personal responses inserted... Erik Nordmark wrote: > Thanks for the comments. A few followup questions below. > > >>> This document doesn't assume that the application protocols are >>> protected by strong security today or in the future. However, it is >>> still useful to assume that the application protocols which care >>> about integrity and/or confidentiality apply the relevant end-to-end >>> security measures, such as IPsec or TLS. >> >>That's a narrow view of e2e security; I would add "and/or applications >>level security." > > > I thought "such as" implied that they were examples and not a complete list. > I can rephrase this to be more inclusive though. > > >>> interface - a node's attachment to a link. >> >>Is this intended to include virtual or pseudo interfaces >>such as tunnel end points? > > > Include. I'll copy the rfc 2460 definition of "link" into the draft > to make this more clear since it explicitly talks about tunnels. > > >>> address - an IP layer name that contains both topological >>> significance and acts as a unique identifier for an >>> interface. >> >>There may be multiple addresses per interface. > > > Added. > > >>> locator - an IP layer topological name for an interface or a >>> set of interfaces. >> >>There may be multiple locators per interface. > > > Added. > > >>> identifier - an IP layer identifier for an IP layer endpoint >>> (stack name in [NSRG]). The transport endpoint is a >>> function of the transport protocol and would >>> typically include the IP identifier plus a port >>> number. >> >>Do we believe there may be multiple identifiers per interface or per host? > > > I think there is utility to have multiple identifiers per stack/host. > For example due to privacy concerns, when using different (and changing over > time) identifiers for certain outbound connections while still having > one (or more) identifiers for inbound communication. I agree. > > Should we make it explicit that the identifiers are not (necessarily) tied > to an interface? I think so. > > >> > 3.1. Application Assumptions >>... >> >>> The second class of applications use existing IP source addresses >>> from outside of their immediate local site as a means of >>> authentication without any form of verification. Today, with source >>> IP address spoofing and TCP sequence number guessing as rampant >>> attacks, such applications are effectively opening themselves for >>> public connectivity and are reliant on other systems, such as >>> firewalls, for overall security. We do not consider this class of >>> systems in this document. >> >>...because they are in any case fully open to all forms of network >>layer spoofing. > > > Added. > > >>> The third class of applications receive existing IP source addresses, >>> but attempt some verification using the DNS, effectively using the >>> FQDN for access control. (This is typically done by performing a >>> reverse lookup from the IP address followed by a forward lookup and >>> verifying that the IP address matches one of the addresses returned >>> from the forward lookup.) These applications are already subject to >>> a number of attacks using techniques like source address spoofing and >>> TCP sequence number guessing since an attacker, knowing this is the >>> case, can simply create a DoS attack using a forged source address >>> that has authentic DNS records. In general this class of >>> applications is strongly discouraged, but it is probably important >>> that a multihoming solution doesn't introduce any new and easier ways >>> to perform such attacks. >> >>But do we desire to make reverse lookup checks for multihomed sites >>succeed, to avoid multihoming failures for hosts using the broken >>technique? > > > For "application compatibility" I think we want to ensure that the > reverse+forward lookups applications do today don't work any less. > But that isn't driven by the threats - it's driven by trying for > as much compatibility as possible. > > Should the threats document say something about this? It probably belongs in draft-lear-multi6-things-to-think-about rather than here. > > >>> Finally, the fifth class of applications use cryptographic security >>> techniques but without strong identity (such as opportunistic IPsec). >>> Thus data integrity with or without confidentiality is provided when >>> communicating with an unknown/unauthenticated principal. Just like >>> the first category above such applications can't perform access >>> control since they do not know the identity of the peer. >> >>This is true *at network level* but they may well have applications >>level strong identity and that may be necessary and sufficient. > > > Correct. I'll add that. Suggested new text for the last sentence: > Just like the first category above such > applications can't perform access control based on network layer information > since they do not know the identity of the peer. However, they might perform > access control using higher-level notions of identity. Fine > > > >> > FQDN - Fully Qualified Domain Name >> >>I would add a reference to RFC 1594, which seems to be the only place >>that FQDN is defined > > > Or FYI18/RFC1983. Yes, that's better. Brian From owner-multi6@ops.ietf.org Tue Jun 8 16:24:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21773 for ; Tue, 8 Jun 2004 16:24:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXn6n-0003mR-8r for multi6-data@psg.com; Tue, 08 Jun 2004 20:22:09 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXn6m-0003m5-2e for multi6@ops.ietf.org; Tue, 08 Jun 2004 20:22:08 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i58KLbLm093521; Tue, 8 Jun 2004 22:21:39 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <817A19BD-B989-11D8-BDA1-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: Comments on draft-nordmark-multi6-threats-01 Date: Tue, 8 Jun 2004 22:22:04 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 8-jun-04, at 1:14, Erik Nordmark wrote: >>> identifier - an IP layer identifier for an IP layer endpoint >>> (stack name in [NSRG]). The transport endpoint >>> is a >>> function of the transport protocol and would >>> typically include the IP identifier plus a port >>> number. >> Do we believe there may be multiple identifiers per interface or per >> host? > I think there is utility to have multiple identifiers per stack/host. > For example due to privacy concerns, when using different (and > changing over > time) identifiers for certain outbound connections while still having > one (or more) identifiers for inbound communication. One very pragmatic reason: if you allow only one management becomes a nightmare as any identifier change is a flag day event. (This is why RFC 2385 never got off the ground until people were convinced the net as a whole would melt down without it.) > Should we make it explicit that the identifiers are not (necessarily) > tied > to an interface? Yes, and we should make it very clear that an identifier that can be used on one interface (physical or otherwise) MUST also be usable as an identifier on any other interface (physical or otherwise) that the system has available. Identifiers should be tied to hosts, not to interfaces. On a related note: the SEND CGA stuff mandates using the subnet prefix in creating the interface identifier and as such makes it impossible to have the same interface identifier in different subnets. I was unable to convince them of the error of their ways and apparently there was no IETF last call or I missed it so now this stupidity is an RFC. We should do our best to make sure there isn't any more of this. From owner-multi6@ops.ietf.org Tue Jun 8 20:50:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14686 for ; Tue, 8 Jun 2004 20:50:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXrGs-000A2T-KB for multi6-data@psg.com; Wed, 09 Jun 2004 00:48:50 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXrGr-000A2F-P2 for multi6@ops.ietf.org; Wed, 09 Jun 2004 00:48:49 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i590kwMf001206; Tue, 8 Jun 2004 18:46:59 -0600 (MDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i590mbQ06359; Wed, 9 Jun 2004 02:48:37 +0200 (MEST) Date: Tue, 8 Jun 2004 17:48:33 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on draft-nordmark-multi6-threats-01 To: Iljitsch van Beijnum Cc: Erik Nordmark , Multi6 In-Reply-To: "Your message with ID" <817A19BD-B989-11D8-BDA1-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Yes, and we should make it very clear that an identifier that can be > used on one interface (physical or otherwise) MUST also be usable as an > identifier on any other interface (physical or otherwise) that the > system has available. Identifiers should be tied to hosts, not to > interfaces. Seems like we all agree. > On a related note: the SEND CGA stuff mandates using the subnet prefix > in creating the interface identifier and as such makes it impossible to > have the same interface identifier in different subnets. I was unable > to convince them of the error of their ways and apparently there was no > IETF last call or I missed it so now this stupidity is an RFC. We > should do our best to make sure there isn't any more of this. It isn't necessarily a bug to have *interface* identifiers that are tied to interfaces, even though we want to have stack names or host identifiers that are not. Erik From owner-multi6@ops.ietf.org Tue Jun 8 21:21:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16044 for ; Tue, 8 Jun 2004 21:21:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXrlq-000Edr-LK for multi6-data@psg.com; Wed, 09 Jun 2004 01:20:50 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXrlp-000Ede-Rj for multi6@ops.ietf.org; Wed, 09 Jun 2004 01:20:49 +0000 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 18:20:49 -0700 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 08 Jun 2004 18:20:49 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 18:20:49 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 18:23:58 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 8 Jun 2004 18:21:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-nordmark-multi6-threats-01 Date: Tue, 8 Jun 2004 18:20:48 -0700 Message-ID: Thread-Topic: Comments on draft-nordmark-multi6-threats-01 thread-index: AcRNvInRQApkM0C4QBi5+qDEcqoYcgAAt+EA From: "Christian Huitema" To: "Erik Nordmark" , "Iljitsch van Beijnum" Cc: "Multi6" X-OriginalArrivalTime: 09 Jun 2004 01:21:03.0678 (UTC) FILETIME=[08045DE0:01C44DC0] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > Yes, and we should make it very clear that an identifier that can be > > used on one interface (physical or otherwise) MUST also be usable as an > > identifier on any other interface (physical or otherwise) that the > > system has available. Identifiers should be tied to hosts, not to > > interfaces. >=20 > Seems like we all agree. If by identifiers you mean the last 64 bits of an IPv6 address, then I certainly disagree. Mandating that hosts should use the same bottom 64 bits on every interface would have some severe privacy implications. The basic assumption should be that third parties should not be able to correlate addresses/locators used on different interfaces or on different networks without the host consent.=20 =20 > > On a related note: the SEND CGA stuff mandates using the subnet prefix > > in creating the interface identifier and as such makes it impossible to > > have the same interface identifier in different subnets. I was unable > > to convince them of the error of their ways and apparently there was no > > IETF last call or I missed it so now this stupidity is an RFC. We > > should do our best to make sure there isn't any more of this. >=20 > It isn't necessarily a bug to have *interface* identifiers that are > tied to interfaces, even though we want to have stack names or host > identifiers that are not. I think SEND is doing the exact right thing, from a privacy and security point of view. -- Christian Huitema From owner-multi6@ops.ietf.org Tue Jun 8 21:27:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16265 for ; Tue, 8 Jun 2004 21:27:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXrrC-000FCr-59 for multi6-data@psg.com; Wed, 09 Jun 2004 01:26:22 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXrr9-000FCY-9n for multi6@ops.ietf.org; Wed, 09 Jun 2004 01:26:19 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i591Q9cP019308; Tue, 8 Jun 2004 19:26:10 -0600 (MDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i591Q6Q07584; Wed, 9 Jun 2004 03:26:07 +0200 (MEST) Date: Tue, 8 Jun 2004 18:26:03 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Comments on draft-nordmark-multi6-threats-01 To: Christian Huitema Cc: Erik Nordmark , Iljitsch van Beijnum , Multi6 In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > If by identifiers you mean the last 64 bits of an IPv6 address, then I > certainly disagree. Mandating that hosts should use the same bottom 64 > bits on every interface would have some severe privacy implications. The > basic assumption should be that third parties should not be able to > correlate addresses/locators used on different interfaces or on > different networks without the host consent. This is in the context of "identifier" as defined in the draft and nothing else: identifier - an IP layer identifier for an IP layer endpoint (stack name in [NSRG]). The transport endpoint is a function of the transport protocol and would typically include the IP identifier plus a port number. There might be use for having multiple interfaces per stack/per host. Do you still disagree? Erik From owner-multi6@ops.ietf.org Wed Jun 9 02:49:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29302 for ; Wed, 9 Jun 2004 02:49:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXwq7-000DgL-MK for multi6-data@psg.com; Wed, 09 Jun 2004 06:45:35 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXwq6-000Dg7-VP for multi6@ops.ietf.org; Wed, 09 Jun 2004 06:45:34 +0000 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 23:45:34 -0700 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 08 Jun 2004 23:45:34 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jun 2004 23:45:31 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 8 Jun 2004 23:45:34 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 8 Jun 2004 23:45:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-nordmark-multi6-threats-01 Date: Tue, 8 Jun 2004 23:45:33 -0700 Message-ID: Thread-Topic: Comments on draft-nordmark-multi6-threats-01 thread-index: AcRNwNg8Uns7QSEBTLmuTIzFxZU+SgAK92jQ From: "Christian Huitema" To: "Erik Nordmark" Cc: "Iljitsch van Beijnum" , "Multi6" X-OriginalArrivalTime: 09 Jun 2004 06:45:49.0639 (UTC) FILETIME=[668E0D70:01C44DED] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > If by identifiers you mean the last 64 bits of an IPv6 address, then I > > certainly disagree. Mandating that hosts should use the same bottom 64 > > bits on every interface would have some severe privacy implications. The > > basic assumption should be that third parties should not be able to > > correlate addresses/locators used on different interfaces or on > > different networks without the host consent. >=20 > This is in the context of "identifier" as defined in the draft > and nothing else: > identifier - an IP layer identifier for an IP layer endpoint > (stack name in [NSRG]). The transport endpoint is a > function of the transport protocol and would > typically include the IP identifier plus a port > number. There might be use for having multiple > interfaces per stack/per host. >=20 > Do you still disagree? Well, I don't know whether hosts should use the same identifier for transactions with different third parties. Here, to, there are privacy implications. If I had a choice, I would go for the minimal possible requirement, i.e. an identifier for the abstract context for which continuity of communications is desired. I would also not assume that we should combine identifier and port number. -- Christian Huitema From owner-multi6@ops.ietf.org Wed Jun 9 03:43:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01225 for ; Wed, 9 Jun 2004 03:43:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXxit-000Kvk-6m for multi6-data@psg.com; Wed, 09 Jun 2004 07:42:11 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXxir-000KvU-Ud for multi6@ops.ietf.org; Wed, 09 Jun 2004 07:42:10 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i597ffLm005493; Wed, 9 Jun 2004 09:41:41 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <823D8D4E-B9E8-11D8-BDA1-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: Comments on draft-nordmark-multi6-threats-01 Date: Wed, 9 Jun 2004 09:42:07 +0200 To: "Christian Huitema" X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 9-jun-04, at 3:20, Christian Huitema wrote: > If by identifiers you mean the last 64 bits of an IPv6 address, then I > certainly disagree. Mandating that hosts should use the same bottom 64 > bits on every interface would have some severe privacy implications. > The > basic assumption should be that third parties should not be able to > correlate addresses/locators used on different interfaces or on > different networks without the host consent. I don't understand what you're saying. Obviously we don't want to force people to use the same bottom 64 bits for different addresses that are otherwise unrelated, as this imposes limitation on address creation as it exists today. But on the other hand, it makes little sense to generate addresses that can't be correlated and then publish a relationship between those addresses in the DNS or reveal this relationship in negotiations with correspondents. The addresses used in multihoming are basically different sides of the same coin, and as such there should be no expectation of privacy here. This is especially true in the case of site multihoming, where leakage of the relationship between two addresses within two prefixes creates a strong presumption that other addresses within those prefixes are related too. As long as it's possible to use RFC 3041 like mechanisms where the identifiers are changed periodically, hosts that desire to hide their long-term identity within the site can do so. Wouldn't that be good enough? > I think SEND is doing the exact right thing, from a privacy and > security > point of view. No, they're FORCING other people to do what they think is the right thing. That's not good. People should be able to choose whether they want to do this or not. From owner-multi6@ops.ietf.org Wed Jun 9 04:54:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03563 for ; Wed, 9 Jun 2004 04:54:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXyp8-000B2m-IO for multi6-data@psg.com; Wed, 09 Jun 2004 08:52:42 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXyp4-000B1w-7D for multi6@ops.ietf.org; Wed, 09 Jun 2004 08:52:38 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i598qVAN061540; Wed, 9 Jun 2004 08:52:31 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i598qVEP288712; Wed, 9 Jun 2004 10:52:31 +0200 Received: from zurich.ibm.com (sig-9-145-141-227.de.ibm.com [9.145.141.227]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA43898; Wed, 9 Jun 2004 10:52:21 +0200 Message-ID: <40C6CFC4.4090708@zurich.ibm.com> Date: Wed, 09 Jun 2004 10:52:20 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Erik Nordmark , Multi6 Subject: SEND IDs [Re: Comments on draft-nordmark-multi6-threats-01] References: <817A19BD-B989-11D8-BDA1-000A95CD987A@muada.com> In-Reply-To: <817A19BD-B989-11D8-BDA1-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch, > On a related note: the SEND CGA stuff mandates using the subnet prefix > in creating the interface identifier and as such makes it impossible to > have the same interface identifier in different subnets. I was unable to > convince them of the error of their ways and apparently there was no > IETF last call or I missed it so now this stupidity is an RFC. We should > do our best to make sure there isn't any more of this. (Co-chair hat is OFF.) I happen to agree with you and disagree with Christian - there should be a mode in SEND in which the CGA address is generated without including the (typically /48) prefix which will vary between ISPs when multihomed. There was a last call, you missed it, and I raised this point in private email and lost. For multi6, I believe we should not feel constrained by this. It would be a fairly simple extension to SEND to allow this, and it might be a very valuable functionality vs security tradeoff for a multihomed site that wanted to run SEND. Brian From owner-multi6@ops.ietf.org Wed Jun 9 06:01:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05782 for ; Wed, 9 Jun 2004 06:01:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXzsB-000OIu-1e for multi6-data@psg.com; Wed, 09 Jun 2004 09:59:55 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXzs7-000OIF-Hm for multi6@ops.ietf.org; Wed, 09 Jun 2004 09:59:51 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id CF81089846; Wed, 9 Jun 2004 12:59:50 +0300 (EEST) Message-ID: <40C6DEA1.40202@piuha.net> Date: Wed, 09 Jun 2004 12:55:45 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter Cc: Iljitsch van Beijnum , Multi6 , Christian Huitema Subject: Re: SEND IDs [Re: Comments on draft-nordmark-multi6-threats-01] References: <817A19BD-B989-11D8-BDA1-000A95CD987A@muada.com> <40C6CFC4.4090708@zurich.ibm.com> In-Reply-To: <40C6CFC4.4090708@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I may be jumping to the middle of this discussion, but I just wanted to clarify the situation with SEND. Iljitsch presented his idea of using the lowest 64 bits as an identifier and we discussed this in the SEND mailing list. My interpretation of the results of that discussion is that people were not convinced about the idea. We explained the need to counteract so called precomputation attacks in SEND and how the prefix plays an important role in that. We also talked about the privacy implications. Finally, I at least wondered what the role of this particular idea is in terms of multi6 WG; are all the multi6 proposals going to rely on the same IID or just some of them? Nevertheless, we also explained to Iljitsch how SEND CGA addresses can be extended, and how such extensions could in future be used to create addresses that are based on CGA but still have the same IID part. Basically, we can add arbitrary data to the input of the CGA generation, and this could be used to include all the prefixes of a host or site in the address. We also explained that this approach would still have a lot of not-so-trivial details to worry about, including what to do when prefixes get deprecated or new ones are added. And due to the way that the CGAs need to be constructed, we'd need to rev the current RFC to accommodate for this. However, I at least am open to such future revisions -- should they prove necessary. Finally, I think that I personally agree with Christian on this issue, at least as far as what the e-mails seem to say. But I'll try to read Erik's document and come back with some better comments later. --Jari Brian E Carpenter wrote: > > Iljitsch, > >> On a related note: the SEND CGA stuff mandates using the subnet prefix >> in creating the interface identifier and as such makes it impossible >> to have the same interface identifier in different subnets. I was >> unable to convince them of the error of their ways and apparently >> there was no IETF last call or I missed it so now this stupidity is an >> RFC. We should do our best to make sure there isn't any more of this. > > > (Co-chair hat is OFF.) > > I happen to agree with you and disagree with Christian - there should > be a mode in SEND in which the CGA address is generated without including > the (typically /48) prefix which will vary between ISPs when multihomed. > > There was a last call, you missed it, and I raised this point in > private email and lost. > > For multi6, I believe we should not feel constrained by this. It would > be a fairly simple extension to SEND to allow this, and it might be > a very valuable functionality vs security tradeoff for a multihomed > site that wanted to run SEND. > > Brian > > > From owner-multi6@ops.ietf.org Wed Jun 9 06:10:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06180 for ; Wed, 9 Jun 2004 06:10:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY01J-0000Ja-2K for multi6-data@psg.com; Wed, 09 Jun 2004 10:09:21 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY01I-0000JI-5M for multi6@ops.ietf.org; Wed, 09 Jun 2004 10:09:20 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i59A8pLm007923; Wed, 9 Jun 2004 12:08:51 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <40C6CFC4.4090708@zurich.ibm.com> References: <817A19BD-B989-11D8-BDA1-000A95CD987A@muada.com> <40C6CFC4.4090708@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <11C06219-B9FD-11D8-BDA1-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: SEND IDs [Re: Comments on draft-nordmark-multi6-threats-01] Date: Wed, 9 Jun 2004 12:09:18 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 9-jun-04, at 10:52, Brian E Carpenter wrote: >> On a related note: the SEND CGA stuff mandates using the subnet >> prefix in creating the interface identifier and as such makes it >> impossible to have the same interface identifier in different >> subnets. I was unable to convince them of the error of their ways and >> apparently there was no IETF last call or I missed it so now this >> stupidity is an RFC. We should do our best to make sure there isn't >> any more of this. > I happen to agree with you and disagree with Christian - there should > be a mode in SEND in which the CGA address is generated without > including > the (typically /48) prefix which will vary between ISPs when > multihomed. > For multi6, I believe we should not feel constrained by this. It would > be a fairly simple extension to SEND to allow this, and it might be > a very valuable functionality vs security tradeoff for a multihomed > site that wanted to run SEND. My idea exactly. However, I find it very unfortunate that something which has a fairly obvious flaw is published as an RFC. It seems to me the IETF is spending inordinate amounts of time on fixing problems that shouldn't have gotten that far in the publication cycle in the first place. (I shouldn't have used the word "stupidity", though.) But let's get our own stuff in order first... From owner-multi6@ops.ietf.org Wed Jun 9 06:19:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06558 for ; Wed, 9 Jun 2004 06:19:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY0AB-0002M4-FT for multi6-data@psg.com; Wed, 09 Jun 2004 10:18:31 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY0AA-0002Lg-Hl for multi6@ops.ietf.org; Wed, 09 Jun 2004 10:18:30 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i59AI2Lm008132; Wed, 9 Jun 2004 12:18:02 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <40C6DEA1.40202@piuha.net> References: <817A19BD-B989-11D8-BDA1-000A95CD987A@muada.com> <40C6CFC4.4090708@zurich.ibm.com> <40C6DEA1.40202@piuha.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <59EFA604-B9FE-11D8-BDA1-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: SEND IDs [Re: Comments on draft-nordmark-multi6-threats-01] Date: Wed, 9 Jun 2004 12:18:28 +0200 To: jari.arkko@piuha.net X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 9-jun-04, at 11:55, Jari Arkko wrote: > Nevertheless, we also explained to Iljitsch how SEND CGA > addresses can be extended, and how such extensions could > in future be used to create addresses that are based on > CGA but still have the same IID part. Basically, we can > add arbitrary data to the input of the CGA generation, > and this could be used to include all the prefixes of > a host or site in the address. We also explained that > this approach would still have a lot of not-so-trivial > details to worry about, including what to do when prefixes > get deprecated or new ones are added. I think there was some confusion about all of this on the SEND list, as this was never the approach I advocated, as this makes everything more complex which is never good in general and especially in the area of security. What I wanted was to allow the use of any on-link prefix in the CGA generation. So if a link has prefixes A and B, and a host generates a CGA interface identifier using prefix A, the host gets to use this same interface identifier to create an address with prefix B. I don't see how this hurts anyone who isn't interested in this, but it would allow switching prefixes and maintaining the lower 64 bits without breaking CGA. Still, we don't know if that's something that's required, so the whole thing may turn out to be moot anyway when we decide on a multi6 mechanism. From owner-multi6@ops.ietf.org Wed Jun 9 07:19:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09268 for ; Wed, 9 Jun 2004 07:19:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY160-000E3s-I9 for multi6-data@psg.com; Wed, 09 Jun 2004 11:18:16 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY15y-000E3E-KW for multi6@ops.ietf.org; Wed, 09 Jun 2004 11:18:14 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id D572E89846; Wed, 9 Jun 2004 13:52:14 +0300 (EEST) Message-ID: <40C6EAE9.5010203@piuha.net> Date: Wed, 09 Jun 2004 13:48:09 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: jari.arkko@piuha.net, Multi6 Subject: Re: SEND IDs [Re: Comments on draft-nordmark-multi6-threats-01] References: <817A19BD-B989-11D8-BDA1-000A95CD987A@muada.com> <40C6CFC4.4090708@zurich.ibm.com> <40C6DEA1.40202@piuha.net> <59EFA604-B9FE-11D8-BDA1-000A95CD987A@muada.com> In-Reply-To: <59EFA604-B9FE-11D8-BDA1-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > I think there was some confusion about all of this on the SEND list, as > this was never the approach I advocated, as this makes everything more > complex which is never good in general and especially in the area of > security. Its possible that me (or others) did not fully understand what you wanted. Please allow also for the possibility that us SENDers have studied the security issues and have a technical reason why the prefix is included. Or that we have a different opinion than you have about the privacy issues. > What I wanted was to allow the use of any on-link prefix in the CGA > generation. So if a link has prefixes A and B, and a host generates a > CGA interface identifier using prefix A, the host gets to use this same > interface identifier to create an address with prefix B. I don't see how > this hurts anyone who isn't interested in this, but it would allow > switching prefixes and maintaining the lower 64 bits without breaking Ah, this was indeed different from what I had understood. Thanks for the clarification. This proposal is better than the other one, because I think we could provide a backwards compatible extension to SEND that allows for this style, by using the CGA Parameters extension to report the prefix A. However, I am not convinced -- yet at least -- that the proposal is secure. I feel uneasy with the thought that someone (say, the NSA) could construct a precomputed table of 2^62 CGA addresses for prefix A, and all that would be needed to take over an address from B:: would be to claim that A is "on-link". It does not immediately follow that the scheme is broken, because we do have security for prefix advertisements as well. But it is an additional worry that I, at least, would rather spend some time analysing rather than adopting it because it might be needed if solution 7/32 is chosen in multi6 :-) > CGA. Still, we don't know if that's something that's required, so the > whole thing may turn out to be moot anyway when we decide on a multi6 > mechanism. Yes. My suggestion is that you work it out in multi6 WG first, and if you come up with a solution that needs an extension or a change to the SEND specifications, we can talk about it at that time. By the way, would DHCP work with the same-IID solution? --Jari From owner-multi6@ops.ietf.org Wed Jun 9 07:49:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10269 for ; Wed, 9 Jun 2004 07:49:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY1ZK-000Jti-01 for multi6-data@psg.com; Wed, 09 Jun 2004 11:48:34 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY1ZG-000Jsx-Av for multi6@ops.ietf.org; Wed, 09 Jun 2004 11:48:30 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5048E2A5A1 for ; Wed, 9 Jun 2004 13:48:29 +0200 (CEST) Received: from [163.117.252.247] (vpn-252-247.uc3m.es [163.117.252.247]) by smtp03.uc3m.es (Postfix) with ESMTP id C966929E55 for ; Wed, 9 Jun 2004 13:48:28 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Multi6 List From: marcelo bagnulo braun Subject: draft-nordmark-multi6-threats-01.txt Date: Tue, 8 Jun 2004 21:35:21 +0200 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Some minor comments about the draft and an attempt to comment on some of the questions posed in the draft Section 1 - Introduction "These attacks pose threats against confidentiality, integrity, and availability." I guess that i could make sense to also include impersonation attacks (or the way you prefer to call them) in which the attacker pretneds to be one party of the communication, since they are also considered in the doc later on it states that: "This document has been developed while considering multihoming solutions architected around a separation of network identity and network location." I think that the threats are actually related to the fact that the the 128 by string used by the routing system to forward the packet differs from the 128 bit string that the ULP sees as identifying the other end of the communication. It doesn't really have to be a split in the most strict sense (where an identifier cannot be a locator) and the threats are then also valid by solutions that use regular addresses both as locators and identifiers (as you mention later) Section 2 "identifier - an IP layer identifier for an IP layer endpoint (stack name in [NSRG]). The transport endpoint is a function of the transport protocol and would typically include the IP identifier plus a port number." Is there a "name" or an "identifier" missing after transport endpoint?, i mean would be that the transport endpoint name is a function.... Section 3.1. application assumptions. I guess that another assumption made by the receiving end of a communication is that the initiator can be reached at the source address included in the initiating packet, since the responder will send reply packets to it. So i guess that some amount of trust is putted in the source address. later on you ask: "[TBD: Does one-way authentication, without mutual authentication, add a different class of applications?]" As i understand this section, the analysis is divided in two: first the initiator end and then the responding end. The initiator, always care about the identity of the target, since it wants to communicate with a given node. So. in this part you discuss the possibility of using TLS to provide strong authentication of the target Next you discuss the responder p.o.v. and you discuss different mechanisms that the responder can use to verify the initiator. So my reading is that responder verification and initiator verification are independent from one another and that the one way authentication is already considered in the analysis. am i missing something? Section 3.4 Flooding attacks today "And in the absence of ingress filtering an attacker can launch simpler DoS attacks by spoofing its source IP address." I don't understand what do you mean here. If there is no ingress filtering this attack may allow an attacker to make a innocent server to attack a victim (and the attacker hasn't to generate the traffic required to do the flooding, so he can attack through a slow link, for instance). So i would say that if no ingress filtering this attack seems a good choice for an attacker which simpler attack am i missing? Section 4. Potential new redirection attacks "This discussion is again framed in the context of independent host identifiers and topological locators." Again, i think that the context for these attacks are that the 128 bit string used to route the packets _may_ differ from the one used by the ULP to identify the endpoints of the communication. It doesn't require that the namespaces are independent imho. NOID and MIP use locators as identifiers and introduce similar threats, i guess Section 4.4. Accepting Packets from Unknown Locators I fail to see the threat presented in this section. I think it is a relevant issue to discuss whether a solution should or not accept packets from unverified source locators, but i don't see the threat of doing it. I do understand that threats apprear when sending traffic to an unverified locator, and i also see the threats that appear if when accepting an unverified locator, some action is taken, like changing the locator used to reach the other end, but if none of this happens, i don't see any threat here. Section 5. GRANULARITY OF REDIRECTION "Discussion: Perhaps the key issue is not about the granularity, but about the lifetime of the state that is created?" imho is about the different scopes of the binding between the multiple locators and the identifier used when a per connection solution is used, the scope of the binding information is limited to that particular connection, both in time and communication sense. This means that if the attacker manages to corrupt that binding information, the attack will only affect the scope of the binding. It will not affect future communication, but it won't neither affect simultaneous communication with the same peer (like for instance in the other direction) So imho time frames is just one aspect of the problem, and granularity seems more general or scopes if you prefer Appendix B "However, the mechanisms for addressing the latter issue can be quite different. One way to prevent premeditated redirection is to simply not introduce a new identifier name space but instead rely on existing name space(s) as in [NOID]; in this case premeditated redirection is as easy or as hard as redirecting an IP address today." I am not sure that i agree with this. imho NOID prevents identity hijacking because there is a trusted third party that informs about the acceptable locator set, and not because there is not a new id space. For instance suppose that an attacker have managed to induce some fake noid state inside a host B , so that a given IP address IPA has an alternative locator IPX Now suppose that the owner of IPA is host A who only has a single address IPA The attacker periodically sends packets to Host B so that Host B preserves this fake state and also to maintain IPX as the preffered address to reach IPA Now when Host B want to initiate a genuine communication with IPA, the noid mechanism within host B will redirect packets to IPX (i don't know if the details of the attack are correct, and i am not trying to present an attack to noid) I am just trying to present that in noid, the identity is represented by the IP addresses, and this identity can be hijacked as well. You don't need a separate id name space to hijcack an identity. (another example could be mip, where the identity is the HoA, and it can be hijacked as well) So, summarizing, i agree with the conclusion, but not with the argument presented, imho NOID avoid the attacks because i relies on a trusted third party (i.e. the DNS) (which makes the situation similar to the current one) later on, it is mentioned that: "In some cases it is also possible to avoid the problem by having (one end of the communication) use ephemeral identifiers as in [WIMP]." Well, in wimp the responding end does have an identity (the hash of the FQDN) which can be hijacked, if the attacker manages to introduce some fake state binding this identity to a fake locator. IMHO wimp avoids this by using a trusted third party to create the initial state (the DNS as in noid) I see three ways to prove the identity ownership: - a trusted third party, which states that a given identity is reachable at a given set of locators, so the endpoint reached at one of this locators is the owner of the identity - CBIDs as disused in the draft - and a static binding, as currently defined in IP, where you trust that the routing system will deliver the packets to the owner of the locator, and since the locator and the identity are one, you prove identity ownership as a subproduct. Later on, the analysis finishes with "Finally, preventing third party DoS attacks is conceptually simpler; it would suffice to somehow verify that the peer is indeed reachable at the new locator before sending a large number of packets to that locator." I think that there are some attacks directed to the identity role and others directed to the locator role. I see communication hijacking, like the threats presented in section 4.1 as threats related to the identity role, where the attacker pretends to be victim and take his place. In this case, i think that basically the identity is stolen OTOH, i see flooding attacks as attacks addressed to the locator role. The attacker pretends to own the victims locator (not the victims identity) So in order to avoid the full set of threats, you need mechanisms to prove the identity ownership, and also the locator ownership, so you can avoid that an attacker steals any of them As i mentioned above, i see these three ways of proving the identity ownership, but t prove locator ownership, i can only see two: - trusted third party - return routability Regards, marcelo From owner-multi6@ops.ietf.org Wed Jun 9 08:56:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12793 for ; Wed, 9 Jun 2004 08:56:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY2bX-000610-3K for multi6-data@psg.com; Wed, 09 Jun 2004 12:54:55 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY2bW-00060l-16 for multi6@ops.ietf.org; Wed, 09 Jun 2004 12:54:54 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i59CsqAN119640 for ; Wed, 9 Jun 2004 12:54:53 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i59CsqrQ176208 for ; Wed, 9 Jun 2004 14:54:52 +0200 Received: from zurich.ibm.com (sig-9-145-141-227.de.ibm.com [9.145.141.227]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA73098 for ; Wed, 9 Jun 2004 14:54:51 +0200 Message-ID: <40C70899.6060200@zurich.ibm.com> Date: Wed, 09 Jun 2004 14:54:49 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Sunday's multi6 bar BOF, and Monday's jabbering Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit For those attending the interim meeting and arriving in Santa Monica on Sunday, there will be a bar BOF starting at about 17:00 PDT (OK, 5 p.m.) somewhere in the Loews Beach Hotel. No agenda, no budget, just an informal discussion for people interested. For those not attending, we hope to have a couple of jabber scribes active on Monday (maybe not all day long). Point your jabber client at multi6 on server ietf.xmpp.org from about 09:00 PDT (16:00 UTC). Brian and Kurtis From owner-multi6@ops.ietf.org Wed Jun 9 09:57:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15859 for ; Wed, 9 Jun 2004 09:57:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY3Xt-000FkD-4y for multi6-data@psg.com; Wed, 09 Jun 2004 13:55:13 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY3Xs-000Fjw-6E for multi6@ops.ietf.org; Wed, 09 Jun 2004 13:55:12 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i59DsdLm011720; Wed, 9 Jun 2004 15:54:41 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <40C70899.6060200@zurich.ibm.com> References: <40C70899.6060200@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9D7673B2-BA1C-11D8-BDA1-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: Sunday's multi6 bar BOF, and Monday's jabbering Date: Wed, 9 Jun 2004 15:55:07 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 9-jun-04, at 14:54, Brian E Carpenter wrote: > For those not attending, we hope to have a couple of jabber > scribes active on Monday (maybe not all day long). Point > your jabber client at multi6 on server ietf.xmpp.org from > about 09:00 PDT (16:00 UTC). If everything goes well we'll also be doing some streaming, probably audio-only or good quality audio and limited quality video. See http://www.muada.com/multi6streaming2.php for more information. Note that this will be unicast streaming using the RTSP protocol, which often doesn't survive NAT. Sorry, but no IPv6 as of yet. :-) From owner-multi6@ops.ietf.org Wed Jun 9 10:11:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16354 for ; Wed, 9 Jun 2004 10:11:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY3me-000Izc-Io for multi6-data@psg.com; Wed, 09 Jun 2004 14:10:28 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY3md-000IzC-Lp for multi6@ops.ietf.org; Wed, 09 Jun 2004 14:10:27 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i59EAtcP028804; Wed, 9 Jun 2004 08:10:55 -0600 (MDT) Received: from blixten (dhcp-ubur03-185-233.East.Sun.COM [129.148.185.233]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i59EArQ03957; Wed, 9 Jun 2004 16:10:54 +0200 (MEST) Date: Wed, 9 Jun 2004 07:10:51 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Comments on draft-nordmark-multi6-threats-01 To: Christian Huitema Cc: Erik Nordmark , Iljitsch van Beijnum , Multi6 In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Well, I don't know whether hosts should use the same identifier for > transactions with different third parties. Here, to, there are privacy > implications. If I had a choice, I would go for the minimal possible > requirement, i.e. an identifier for the abstract context for which > continuity of communications is desired. I would also not assume that we > should combine identifier and port number. Section 8 in the draft talks about privacy considerations. Given that the stack doesn't (and can't) know the continuity requirements for some communication - this can be a lot more than the lifetime of a transport connection - I think we need to have identifiers that can be stable for more than the lifetime of a single transport connection. Otherwise, even simple application patternss such as "call me back when done" (which would cause a second transport connection in the reverse direction) would fail. Erik From owner-multi6@ops.ietf.org Wed Jun 9 10:19:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16639 for ; Wed, 9 Jun 2004 10:19:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY3uO-000Jmo-VQ for multi6-data@psg.com; Wed, 09 Jun 2004 14:18:28 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY3uO-000JmV-6g for multi6@ops.ietf.org; Wed, 09 Jun 2004 14:18:28 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i59EImcH026782; Wed, 9 Jun 2004 07:18:49 -0700 (PDT) Received: from blixten (dhcp-ubur03-185-233.East.Sun.COM [129.148.185.233]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i59EIkQ04685; Wed, 9 Jun 2004 16:18:47 +0200 (MEST) Date: Wed, 9 Jun 2004 07:18:44 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: SEND IDs [Re: Comments on draft-nordmark-multi6-threats-01] To: jari.arkko@piuha.net Cc: Brian E Carpenter , Iljitsch van Beijnum , Multi6 , Christian Huitema In-Reply-To: "Your message with ID" <40C6DEA1.40202@piuha.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Finally, > I at least wondered what the role of this particular idea > is in terms of multi6 WG; are all the multi6 proposals > going to rely on the same IID or just some of them? My understanding is that there is one or a few multi6 proposals that would require using the same IID, because those proposals treat that 64 byte quantity as the identifier for the host. Other proposals don't care about the IID (at least as a 1st order approximation); one can envision 2nd order effects related to wanting to compress the list of a lot of locators assigned to a host and if those locators have the same 64 bits the compression could take advantage of this. Erik From owner-multi6@ops.ietf.org Wed Jun 9 10:45:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18059 for ; Wed, 9 Jun 2004 10:45:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY4J2-000NaP-4f for multi6-data@psg.com; Wed, 09 Jun 2004 14:43:56 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY4J0-000NZv-UK for multi6@ops.ietf.org; Wed, 09 Jun 2004 14:43:55 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4344C2752A; Wed, 9 Jun 2004 16:43:53 +0200 (CEST) Received: from [163.117.252.247] (vpn-252-247.uc3m.es [163.117.252.247]) by smtp02.uc3m.es (Postfix) with ESMTP id 972BC27904; Wed, 9 Jun 2004 16:43:52 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <49443425-BA22-11D8-B6DC-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Multi6 , Christian Huitema , Iljitsch van Beijnum From: marcelo bagnulo braun Subject: Re: Comments on draft-nordmark-multi6-threats-01 Date: Wed, 9 Jun 2004 16:35:42 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, El 09/06/2004, a las 16:10, Erik Nordmark escribi=F3: >> Well, I don't know whether hosts should use the same identifier for >> transactions with different third parties. Here, to, there are = privacy >> implications. If I had a choice, I would go for the minimal possible >> requirement, i.e. an identifier for the abstract context for which >> continuity of communications is desired. I would also not assume that=20= >> we >> should combine identifier and port number. > > Section 8 in the draft talks about privacy considerations. i guess that also in this point, we should follow the general criteria=20= of not making things worse than currently are. SO the level of privacy provided in current single homed IPv6 should be=20= provided in multihoming, i guess. (a possibility could be to include the current level of privacy support=20= in IPv6, just as the other current state of the art are presented.) regards, marcelo > > Given that the stack doesn't (and can't) know the continuity=20 > requirements > for some communication - this can be a lot more than the lifetime of > a transport connection - I think we need to have identifiers that can=20= > be > stable for more than the lifetime of a single transport connection. > > Otherwise, even simple application patternss such as "call me back=20 > when done" > (which would cause a second transport connection in the reverse=20 > direction) > would fail. > > Erik > > > From owner-multi6@ops.ietf.org Thu Jun 10 08:56:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00393 for ; Thu, 10 Jun 2004 08:56:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYP3s-000OeY-Rp for multi6-data@psg.com; Thu, 10 Jun 2004 12:53:40 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYP3r-000OeB-Gv for multi6@ops.ietf.org; Thu, 10 Jun 2004 12:53:39 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5ACrWcP018527; Thu, 10 Jun 2004 06:53:32 -0600 (MDT) Received: from blixten (dhcp-ubur03-185-233.East.Sun.COM [129.148.185.233]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5ACrUQ17758; Thu, 10 Jun 2004 14:53:30 +0200 (MEST) Date: Thu, 10 Jun 2004 05:53:27 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-nordmark-multi6-threats-01.txt To: marcelo bagnulo braun Cc: Multi6 List In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Thanks for the comments. > Section 1 - Introduction > > "These attacks pose threats against confidentiality, > integrity, and availability." > > I guess that i could make sense to also include impersonation attacks > (or the way you prefer to call them) in which the attacker pretneds to > be one party of the communication, since they are also considered in > the doc I think such attacks are and end to accomplish threats against the above. For instance, I might be successful in convincing somebody that I am Santa Claus, but if they are not going to engage Santa in some way that has no effect. If they do believe that they are having confidential communication with Santa Claus but they are instead communicating (with confidentiality) with me then there was an attack on confidentiality. But perhaps "authenticity" should be added to the above list? > later on it states that: > > "This document has been developed while considering multihoming > solutions architected around a separation of network identity and > network location." > > I think that the threats are actually related to the fact that the the > 128 by string used by the routing system to forward the packet differs > from the 128 bit string that the ULP sees as identifying the other end > of the communication. It doesn't really have to be a split in the most > strict sense (where an identifier cannot be a locator) and the threats > are then also valid by solutions that use regular addresses both as > locators and identifiers (as you mention later) Agreed. But I don't see anything in the quoted text that says something about there being a new name space for identifiers. So how would you propose to make that text more clear that a new name space isn't assumed? How about I make it say: This document has been developed while considering multihoming solutions architected around a separation of network identity and network location, whether or not this separation implies the introduction of a new and separate identifier name space. > Section 2 > > "identifier - an IP layer identifier for an IP layer endpoint > (stack name in [NSRG]). The transport endpoint is a > function of the transport protocol and would > typically include the IP identifier plus a port > number." > > Is there a "name" or an "identifier" missing after transport endpoint?, > i mean would be that the transport endpoint name is a function.... Yes, it reads better with that added. I hope we don't have to argue whether it should be "transport name" or "transport identifier". I'll put a "name" in there. > Section 3.1. application assumptions. > > I guess that another assumption made by the receiving end of a > communication is that the initiator can be reached at the source > address included in the initiating packet, since the responder will > send reply packets to it. So i guess that some amount of trust is > putted in the source address. Yes, but I think this assumption is more fundamental than being just about trust. Do you think I should add something about it? > later on you ask: > "[TBD: Does one-way authentication, without mutual authentication, > add a > different class of applications?]" > > As i understand this section, the analysis is divided in two: first the > initiator end and then the responding end. > The initiator, always care about the identity of the target, since it > wants to communicate with a given node. So. in this part you discuss > the possibility of using TLS to provide strong authentication of the > target > Next you discuss the responder p.o.v. and you discuss different > mechanisms that the responder can use to verify the initiator. > > So my reading is that responder verification and initiator verification > are independent from one another and that the one way authentication is > already considered in the analysis. am i missing something? Yes, you're right. Thanks for making that clear to me. > Section 3.4 Flooding attacks today > > "And in the absence of ingress filtering an attacker can > launch simpler DoS attacks by spoofing its source IP address." > > I don't understand what do you mean here. If there is no ingress > filtering this attack may allow an attacker to make a innocent server > to attack a victim (and the attacker hasn't to generate the traffic > required to do the flooding, so he can attack through a slow link, for > instance). So i would say that if no ingress filtering this attack > seems a good choice for an attacker which simpler attack am i missing? Agree that the above sentence is out of place. What does fit for that paragraph, which has "in the presence of ingress filtering" earlier, is something like: And in the absence of ingress filtering an attacker would either need to be present on the path initially and then move away, or the attacker would need to be able to perform the setup of the communication "blind" i.e., without seeing the return traffic (which in the case of TCP implies guessing the initial sequence number). > Section 4. Potential new redirection attacks > > "This discussion is again > framed in the context of independent host identifiers and topological > locators." > > Again, i think that the context for these attacks are that the 128 bit > string used to route the packets _may_ differ from the one used by the > ULP to identify the endpoints of the communication. It doesn't require > that the namespaces are independent imho. NOID and MIP use locators as > identifiers and introduce similar threats, i guess Good point. I'll reword it. > Section 4.4. Accepting Packets from Unknown Locators > > I fail to see the threat presented in this section. I think it is a > relevant issue to discuss whether a solution should or not accept > packets from unverified source locators, but i don't see the threat of > doing it. I do understand that threats apprear when sending traffic to > an unverified locator, and i also see the threats that appear if when > accepting an unverified locator, some action is taken, like changing > the locator used to reach the other end, but if none of this happens, i > don't see any threat here. The key sentence is: "In the current Internet, an attacker can't inject packets with arbitrary source addresses into a session if there is ingress filtering present," The threat in general is accepting packets (such as TCP RST packets) which can cause DoS and/or corruption of the application data stream. When there is no ingress filtering in the network, this is something that the endpoints need to sort out themselves. However, deploying ingress filtering (or source address filtering in general) helps in today's Internet. This section tries to state the concerns that perhaps we want ingress filtering to help even when a multihoming solution is deployed. Do you have suggestions on how to make this more clear? > Section 5. GRANULARITY OF REDIRECTION > > "Discussion: Perhaps the key issue is not about the granularity, > but about the lifetime of the state that is created?" > > imho is about the different scopes of the binding between the multiple > locators and the identifier used > when a per connection solution is used, the scope of the binding > information is limited to that particular connection, both in time and > communication sense. This means that if the attacker manages to corrupt > that binding information, the attack will only affect the scope of the > binding. It will not affect future communication, but it won't neither > affect simultaneous communication with the same peer (like for instance > in the other direction) > > So imho time frames is just one aspect of the problem, and granularity > seems more general or scopes if you prefer Yes, but this section, which is subject to discussion and by no means is finished, tries to point out that by making the scope smaller by applying the redirection to only one connection, we would be making more work for the legitimate applications (such as short-lived http connections) as well as attackers, and the ratio by which we make things harder seems to be the same for the legitimate guys and the attackers. That doesn't seem like a good approach to improving security. For security you want things (like keys on the front door of a house) that are a little bit inconvinient for the legimate parties, but make it significantly harder for an attacker. The "time" aspect of the scope seems to be closer to this; leaving any multihoming state around after it is no longer used by the ULP might not provide much benefits for the legimate users but leaves a door open that makes it easier for attackers to do premediated attacks. > > Appendix B > > "However, the mechanisms for addressing the latter issue can be quite > different. One way to prevent premeditated redirection is to simply > not introduce a new identifier name space but instead rely on > existing name space(s) as in [NOID]; in this case premeditated > redirection is as easy or as hard as redirecting an IP address > today." > > I am not sure that i agree with this. imho NOID prevents identity > hijacking because there is a trusted third party that informs about the > acceptable locator set, and not because there is not a new id space. You're right. It is the re-use of the existing name space *and* presumed security mechanisms associated with the looking up of objects in that name space that is important. > For instance suppose that an attacker have managed to induce some fake > noid state inside a host B , so that a given IP address IPA has an > alternative locator IPX And it can do this, in the case of NOID, by attacking the DNS. > later on, it is mentioned that: > > "In some cases it > is also possible to avoid the problem by having (one end of the > communication) use ephemeral identifiers as in [WIMP]." > > Well, in wimp the responding end does have an identity (the hash of the > FQDN) which can be hijacked, if the attacker manages to introduce some > fake state binding this identity to a fake locator. IMHO wimp avoids > this by using a trusted third party to create the initial state (the > DNS as in noid) Yes, for the responding end. The interesting thing I tried to bring out is that for the end that has the ephemeral ID, you can skirt around the premediated attacks (assuming the solution has a robust way to pick a new ID when one is in use/stolen). > I see three ways to prove the identity ownership: > > - a trusted third party, which states that a given identity is > reachable at a given set of locators, so the endpoint reached at one of > this locators is the owner of the identity > > - CBIDs as disused in the draft > > - and a static binding, as currently defined in IP, where you trust > that the routing system will deliver the packets to the owner of the > locator, and since the locator and the identity are one, you prove > identity ownership as a subproduct. Agreed. And we also have the option to think about ephemeral IDs where they make sense. > Later on, the analysis finishes with > > "Finally, preventing third party DoS attacks is conceptually simpler; > it would suffice to somehow verify that the peer is indeed reachable > at the new locator before sending a large number of packets to that > locator." > > I think that there are some attacks directed to the identity role and > others directed to the locator role. > I see communication hijacking, like the threats presented in section > 4.1 as threats related to the identity role, where the attacker > pretends to be victim and take his place. In this case, i think that > basically the identity is stolen > OTOH, i see flooding attacks as attacks addressed to the locator role. > The attacker pretends to own the victims locator (not the victims > identity) > > So in order to avoid the full set of threats, you need mechanisms to > prove the identity ownership, and also the locator ownership, so you > can avoid that an attacker steals any of them I think proving locator ownership (e.g. by verifying using DNSsec through ip6.arpa that the locator has indeed been assigned to the node in question) is one way to prevent 3rd party DoS. But it might be stronger than we need. Another approach is just to have the peer identity show that it is present at the claimed locator, which is weaker (and how weak depends on how the details of the mechanism by which it would show this). My point is that the latter approach doesn't talk about locator ownership at all. > As i mentioned above, i see these three ways of proving the identity > ownership, but t prove locator ownership, i can only see two: > > - trusted third party > - return routability I think you are overextending the "ownership" term when you apply it to return routability; I think this is more about "presence" at the locator. And there can be very different strength proofs of presence, from just responding "yes, it's me" to having CGA/CBID based proofs that the entity at that locator holds the private key. But it is very good that we are starting to discuss the initial attempt to capture these aspects in the appendix; understanding this helps comparing different possible approaches. Erik From owner-multi6@ops.ietf.org Thu Jun 10 14:33:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22875 for ; Thu, 10 Jun 2004 14:33:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYUK7-000Gur-76 for multi6-data@psg.com; Thu, 10 Jun 2004 18:30:47 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYUK6-000GuA-Ci for multi6@ops.ietf.org; Thu, 10 Jun 2004 18:30:46 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5AIUcil014674; Thu, 10 Jun 2004 12:30:39 -0600 (MDT) Received: from blixten (dhcp-ubur03-185-233.East.Sun.COM [129.148.185.233]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5AIUaQ20343; Thu, 10 Jun 2004 20:30:36 +0200 (MEST) Date: Thu, 10 Jun 2004 11:30:32 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on draft-nordmark-multi6-threats-01 To: marcelo bagnulo braun Cc: Erik Nordmark , Multi6 , Christian Huitema , Iljitsch van Beijnum In-Reply-To: "Your message with ID" <49443425-BA22-11D8-B6DC-000D93ACD0FE@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > i guess that also in this point, we should follow the general criteria > of not making things worse than currently are. > SO the level of privacy provided in current single homed IPv6 should be > provided in multihoming, i guess. > > (a possibility could be to include the current level of privacy support > in IPv6, just as the other current state of the art are presented.) Good point. I guess we can start with IPv4 where in some cases (dialup being the prime example) the IPv4 addresses change over time. In IPv6 the temporary addresses RFC provide a way to make it harder to correlate packets from the same machine over time. So I think the "do no harm" criteria means that the introduction of multihoming support should still provide the same ability as we have in IPv6 with temporary addresses. Erik From owner-multi6@ops.ietf.org Thu Jun 10 15:59:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28071 for ; Thu, 10 Jun 2004 15:59:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYVgW-00040h-V0 for multi6-data@psg.com; Thu, 10 Jun 2004 19:58:00 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYVgV-00040K-M0 for multi6@ops.ietf.org; Thu, 10 Jun 2004 19:57:59 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5AJvTLm043085; Thu, 10 Jun 2004 21:57:29 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <771D86ED-BB18-11D8-BDA1-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: Comments on draft-nordmark-multi6-threats-01 Date: Thu, 10 Jun 2004 21:57:55 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 10-jun-04, at 20:30, Erik Nordmark wrote: >> (a possibility could be to include the current level of privacy >> support >> in IPv6, just as the other current state of the art are presented.) > Good point. > I guess we can start with IPv4 where in some cases (dialup being the > prime example) the IPv4 addresses change over time. But sometimes it stays the same for very long periods of time. > In IPv6 the temporary addresses RFC provide a way to make it > harder to correlate packets from the same machine over time. Which can also be quite problematic in certain situations (DoS, for instance). The original intention of RFC 3041 was to make sure that when a host moves from one prefix to another, its correspondents can't track it by the interface identifier that stays the same. Being able to hide within a subnet prefix that doesn't change is an extra feature. Not being able to support this feature doesn't automatically disqualify a multihoming solution, IMO. > So I think the "do no harm" criteria means that the introduction > of multihoming support should still provide the same ability as we > have in IPv6 with temporary addresses. We can't let ourselves be constrained by arbitrary features of the current architecture. If the features are important, sure, we must support them. But having to do so just because it can be done today makes has the potential to disqualify very useful multihoming solutions without good reason. From owner-multi6@ops.ietf.org Thu Jun 10 17:19:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00755 for ; Thu, 10 Jun 2004 17:19:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYWvq-000Dta-Fo for multi6-data@psg.com; Thu, 10 Jun 2004 21:17:54 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYWvp-000DtJ-LI for multi6@ops.ietf.org; Thu, 10 Jun 2004 21:17:53 +0000 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id QAA10455; Thu, 10 Jun 2004 16:17:46 -0500 (CDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i5ALHji05746; Thu, 10 Jun 2004 14:17:45 -0700 (PDT) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Thu, 10 Jun 2004 14:17:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-nordmark-multi6-threats-01 Date: Thu, 10 Jun 2004 14:17:38 -0700 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDD549@xch-nw-09.nw.nos.boeing.com> Thread-Topic: Comments on draft-nordmark-multi6-threats-01 Thread-Index: AcRNwaW/1vIIvbcST3Ci310G+ltDFwBbZZfA From: "Fleischman, Eric" To: "Erik Nordmark" , "Christian Huitema" Cc: "Iljitsch van Beijnum" , "Multi6" X-OriginalArrivalTime: 10 Jun 2004 21:17:39.0436 (UTC) FILETIME=[5C0962C0:01C44F30] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Erik, > identifier - an IP layer identifier for an IP layer endpoint > (stack name in [NSRG]). I am bothered by this definition. The way I read it, it implies that an = IP layer endpoint is the protocol stack. That is true of every protocol = system that I know (including OSI) except for the Internet protocol = suite. For the Internet protocol suite, the IP layer endpoint is a = network interface.=20 Here is where the difference is manifest: for OSI and other protocols = with a NSAP (network service access point -- i.e., a stack interface at = the network layer), every network interface on that device has the same = network layer address. However, for the Internet protocol suite, every = network interface has a different IP address. This is why you need to = eliminate the text "(stack name in [NSRG])" from your definition. BTW: has multi6 actually considered redefining IP addresses to actually = become stack interfaces at the IP layer? If you have, I think that you = may agree with me that most/many of the *node* multihoming problems go = away. --Eric=20 From owner-multi6@ops.ietf.org Thu Jun 10 19:41:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06833 for ; Thu, 10 Jun 2004 19:41:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYZ8s-000717-Ds for multi6-data@psg.com; Thu, 10 Jun 2004 23:39:30 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYZ8q-00070m-SI for multi6@ops.ietf.org; Thu, 10 Jun 2004 23:39:29 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id E7AF686AF6; Thu, 10 Jun 2004 19:39:27 -0400 (EDT) To: multi6@ops.ietf.org Subject: RE: Comments on draft-nordmark-multi6-threats-01 Cc: jnc@mercury.lcs.mit.edu Message-Id: <20040610233927.E7AF686AF6@mercury.lcs.mit.edu> Date: Thu, 10 Jun 2004 19:39:27 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Fleischman, Eric" >> identifier - an IP layer identifier for an IP layer endpoint >> (stack name in [NSRG]). > I am bothered by this definition. The way I read it, it implies that an > IP layer endpoint is the protocol stack. That is true of every protocol > system that I know (including OSI) except for the Internet protocol > suite. For the Internet protocol suite, the IP layer endpoint is a > network interface. To start with, terminology nit - and lest you think terminology nits are not worthy of notice, let me yet again roll out one of my faourite quotations: "I am far from thinking that nomenclature is a remedy for every defect in art or science: still I cannot but feel that confusion of terms generally springs from, and always leads to, confusion of ideas." -- John Louis Petit, "Architectural Studies in France", 1854 I'm going to complain about your use of the term "IP layer endpoint" above, because you've seriously warped the definition of "endpoint". Where you said "IP layer endpoint" I think you mean to say something like "the thing(s) named by the name(s) of the existing IP layer" - so, to restate your line above: "the thing named by the names of the existing IP layer is a network interface". (Which is not quite true either, but I'll ignore that for now.) Or perhaps you meant "the fundamental entity of the IP layer is a network interface"; I can't be sure which. In either case, an "endpoint" (as originally defined in: http://users.exis.net/~jnc/tech/endpoints.txt about a decade ago) is a name for the entire communicating entity, including the transport protocol(s), etc. So to use "endpoint" in any other way, as you did, is really confusing. > Here is where the difference is manifest: for OSI and other protocols > with a NSAP (network service access point -- i.e., a stack interface at > the network layer), every network interface on that device has the same > network layer address. However, for the Internet protocol suite, every > network interface has a different IP address. This is why you need to > eliminate the text "(stack name in [NSRG])" from your definition. This is like saying "we need to eliminate family names and replace them with personal ID numbers". The thing is that family names *aren't* names for individuals, so there's no way any kind of name for an individual (no matter what its syntax or properties) could replace them. Family names name groups of individuals, not a single individual. Similarly, these "identifiers/stack-names" name a *different kind of thing* than network interfaces - which is why they have different names. > has multi6 actually considered redefining IP addresses to actually > become stack interfaces at the IP layer? If you have, I think that you > may agree with me that most/many of the *node* multihoming problems go > away. Alas, we need to explicitly recognize (and name) interfaces *as well*, and give different interfaces different names, for multi-homing to scale to large sizes. This is because if all the interfaces have the same name, then since interfaces are where the routing system sends packets (i.e. it looks at interface names in packet headers, to get packets where they are going), then the routing has to track interfaces (because if interface "X" appears at N widely-separated places in the network, it has to keep track of where at least one "X" is, and how to get there) - and that doesn't scale. Put another way, the routing has to have 'routing-names' which are topologically sensitive; i.e. have to information about *where* they are encoded into them. Therefore, the routing-names for two interfaces which are connected to different parts of the network cannot be the same. Therefore, if you want to have one name apply to an entire host, including several interfaces, it cannot be a routing-name. Noel From owner-multi6@ops.ietf.org Thu Jun 10 23:42:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14522 for ; Thu, 10 Jun 2004 23:42:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYctX-000CdT-Lu for multi6-data@psg.com; Fri, 11 Jun 2004 03:39:55 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYctW-000Cd1-H1 for multi6@ops.ietf.org; Fri, 11 Jun 2004 03:39:54 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5B3dqx28777; Fri, 11 Jun 2004 06:39:52 +0300 (EET DST) X-Scanned: Fri, 11 Jun 2004 06:39:17 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i5B3dHrA032126; Fri, 11 Jun 2004 06:39:17 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00zAOy8i; Fri, 11 Jun 2004 06:39:16 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5B3dFH14310; Fri, 11 Jun 2004 06:39:16 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 11 Jun 2004 06:39:14 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 11 Jun 2004 06:39:15 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-nordmark-multi6-threats-01.txt Date: Fri, 11 Jun 2004 06:39:14 +0300 Message-ID: Thread-Topic: draft-nordmark-multi6-threats-01.txt Thread-Index: AcRO6sITcOUe/AzwRJW7ite/+qBk5QAeZ7rA From: To: , Cc: X-OriginalArrivalTime: 11 Jun 2004 03:39:15.0114 (UTC) FILETIME=[AAEC98A0:01C44F65] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Erik & Marcelo, > > Section 1 - Introduction > >=20 > > "These attacks pose threats against confidentiality, > > integrity, and availability." > >=20 > > I guess that i could make sense to also include impersonation = attacks=20 > > (or the way you prefer to call them) in which the attacker pretneds = to=20 > > be one party of the communication, since they are also considered in = > > the doc >=20 > I think such attacks are and end to accomplish threats against the = above. > For instance, I might be successful in convincing somebody that I am > Santa Claus, but if they are not going to engage Santa in some way > that has no effect. If they do believe that they are having = confidential > communication with Santa Claus but they are instead communicating > (with confidentiality) with me then there was an attack on = confidentiality. > But perhaps "authenticity" should be added to the above list? Well, I think that authenticated at this layer is very difficult. One = could make a case that you could authenticate Santa Claus' IP address but not Santa himself - what if one of his elves is actually talking to you, = Erik? What we should consider is that a multihoming event doesn't cause any redirection attacks, so that at first you were talking to Santa Claus' computer then after the event you were talking to Mrs. Claus' computer. Trying to authenticate the user at the multi6 level probably would be=20 impossible & goes beyond the 'do no harm' edict. =20 John From owner-multi6@ops.ietf.org Fri Jun 11 03:12:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03411 for ; Fri, 11 Jun 2004 03:12:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYgAp-0009Dt-2p for multi6-data@psg.com; Fri, 11 Jun 2004 07:09:59 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYgAn-0009Da-Hi for multi6@ops.ietf.org; Fri, 11 Jun 2004 07:09:57 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7D2D4276BC; Fri, 11 Jun 2004 09:09:56 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp02.uc3m.es (Postfix) with ESMTP id 6842527586; Fri, 11 Jun 2004 09:09:56 +0200 (CEST) In-Reply-To: <20040610233927.E7AF686AF6@mercury.lcs.mit.edu> References: <20040610233927.E7AF686AF6@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <69956DC8-BB76-11D8-B6DC-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: multi6@ops.ietf.org From: marcelo bagnulo braun Subject: Re: Comments on draft-nordmark-multi6-threats-01 Date: Fri, 11 Jun 2004 09:10:25 +0200 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 11/06/2004, a las 1:39, Noel Chiappa escribi=F3: >> From: "Fleischman, Eric" > >>> identifier - an IP layer identifier for an IP layer endpoint >>> (stack name in [NSRG]). > >> I am bothered by this definition. The way I read it, it implies that=20= >> an >> IP layer endpoint is the protocol stack. That is true of every=20 >> protocol >> system that I know (including OSI) except for the Internet protocol >> suite. For the Internet protocol suite, the IP layer endpoint is a >> network interface. > > To start with, terminology nit - and lest you think terminology nits=20= > are not > worthy of notice, let me yet again roll out one of my faourite=20 > quotations: > > "I am far from thinking that nomenclature is a remedy for every=20 > defect in > art or science: still I cannot but feel that confusion of terms=20 > generally > springs from, and always leads to, confusion of ideas." > > -- John Louis Petit, "Architectural Studies in France", 1854 > i still think that sooner or later we will need a terminology draft so=20= we all share the same definitions when we use certain words i know that this will probably imply long discussions about which words=20= to use, though Regards, marcelo= From owner-multi6@ops.ietf.org Fri Jun 11 03:13:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03454 for ; Fri, 11 Jun 2004 03:13:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYgDY-0009Qz-V2 for multi6-data@psg.com; Fri, 11 Jun 2004 07:12:48 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYgDY-0009Qh-4n for multi6@ops.ietf.org; Fri, 11 Jun 2004 07:12:48 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6E9332773A; Fri, 11 Jun 2004 09:12:47 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp02.uc3m.es (Postfix) with ESMTP id 5715E276E1; Fri, 11 Jun 2004 09:12:47 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Multi6 , Christian Huitema , Iljitsch van Beijnum From: marcelo bagnulo braun Subject: Re: Comments on draft-nordmark-multi6-threats-01 Date: Fri, 11 Jun 2004 09:13:16 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 10/06/2004, a las 20:30, Erik Nordmark escribi=F3: >> i guess that also in this point, we should follow the general = criteria >> of not making things worse than currently are. >> SO the level of privacy provided in current single homed IPv6 should=20= >> be >> provided in multihoming, i guess. >> >> (a possibility could be to include the current level of privacy=20 >> support >> in IPv6, just as the other current state of the art are presented.) > > Good point. > I guess we can start with IPv4 where in some cases (dialup being the > prime example) the IPv4 addresses change over time. > In IPv6 the temporary addresses RFC provide a way to make it > harder to correlate packets from the same machine over time. > > So I think the "do no harm" criteria means that the introduction > of multihoming support should still provide the same ability as we > have in IPv6 with temporary addresses. > agree i guess it should also be noted that in order to be reachable, a node=20 has to have a stable IP address (stable means compatible with DNS times=20= for instance) (which is obvious anyway, that in order to be reachable a=20= node cannot be anonymous :-) regards, marcelo > Erik > > From owner-multi6@ops.ietf.org Fri Jun 11 03:16:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03651 for ; Fri, 11 Jun 2004 03:16:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYgGS-0009iI-IG for multi6-data@psg.com; Fri, 11 Jun 2004 07:15:48 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYgGR-0009i3-ET for multi6@ops.ietf.org; Fri, 11 Jun 2004 07:15:47 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B7DEC2771A; Fri, 11 Jun 2004 09:15:46 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp02.uc3m.es (Postfix) with ESMTP id A17D5276BC; Fri, 11 Jun 2004 09:15:46 +0200 (CEST) In-Reply-To: <771D86ED-BB18-11D8-BDA1-000A95CD987A@muada.com> References: <771D86ED-BB18-11D8-BDA1-000A95CD987A@muada.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3A46CB4A-BB77-11D8-B6DC-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: 7bit Cc: Multi6 , Erik Nordmark From: marcelo bagnulo braun Subject: Re: Comments on draft-nordmark-multi6-threats-01 Date: Fri, 11 Jun 2004 09:16:16 +0200 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Which can also be quite problematic in certain situations (DoS, for > instance). The original intention of RFC 3041 was to make sure that > when a host moves from one prefix to another, its correspondents can't > track it by the interface identifier that stays the same. Being able > to hide within a subnet prefix that doesn't change is an extra > feature. which we have available today, and that provides some privacy, so loosing it is loosing some capability > Not being able to support this feature doesn't automatically > disqualify a multihoming solution, IMO. i agree, but we have to be aware of what we are loosing and whether the trade off is acceptable > >> So I think the "do no harm" criteria means that the introduction >> of multihoming support should still provide the same ability as we >> have in IPv6 with temporary addresses. > > We can't let ourselves be constrained by arbitrary features of the > current architecture. If the features are important, sure, we must > support them. But having to do so just because it can be done today > makes has the potential to disqualify very useful multihoming > solutions without good reason. Fully agree. so let's first describe what we have and how useful this is, and then we can evaluate the trade off we are making when accepting a new solution that don't support certain features. regards, marcelo > > From owner-multi6@ops.ietf.org Fri Jun 11 06:06:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09715 for ; Fri, 11 Jun 2004 06:06:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYiuj-0000dn-48 for multi6-data@psg.com; Fri, 11 Jun 2004 10:05:33 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYiuh-0000dB-4T for multi6@ops.ietf.org; Fri, 11 Jun 2004 10:05:31 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5BA5OfV082626; Fri, 11 Jun 2004 10:05:24 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5BA5NB1177848; Fri, 11 Jun 2004 12:05:23 +0200 Received: from zurich.ibm.com (sig-9-145-243-226.de.ibm.com [9.145.243.226]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA49206; Fri, 11 Jun 2004 12:05:22 +0200 Message-ID: <40C983E1.1040609@zurich.ibm.com> Date: Fri, 11 Jun 2004 12:05:21 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 CC: Iljitsch van Beijnum Subject: Re: Comments on draft-nordmark-multi6-threats-01 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit marcelo bagnulo braun wrote: > > El 10/06/2004, a las 20:30, Erik Nordmark escribió: > >>> i guess that also in this point, we should follow the general criteria >>> of not making things worse than currently are. >>> SO the level of privacy provided in current single homed IPv6 should be >>> provided in multihoming, i guess. >>> >>> (a possibility could be to include the current level of privacy support >>> in IPv6, just as the other current state of the art are presented.) >> >> >> Good point. >> I guess we can start with IPv4 where in some cases (dialup being the >> prime example) the IPv4 addresses change over time. >> In IPv6 the temporary addresses RFC provide a way to make it >> harder to correlate packets from the same machine over time. >> >> So I think the "do no harm" criteria means that the introduction >> of multihoming support should still provide the same ability as we >> have in IPv6 with temporary addresses. >> > > agree > i guess it should also be noted that in order to be reachable, a node > has to have a stable IP address (stable means compatible with DNS times > for instance) (which is obvious anyway, that in order to be reachable a > node cannot be anonymous :-) And we have to be a bit careful here too. The applicability of RFC 3041, or of CGAs which are the same but more so, is probably not to corporate networks (which is what the word "site multihoming" makes me think of). A network that is grown-up enough to require multihoming has almost certainly given up anonymity at the /48 level already, and at that point anonymity at the /128 level may not have much value. On the contrary, traceability of /128s may be *required*. Brian From owner-multi6@ops.ietf.org Fri Jun 11 06:44:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11954 for ; Fri, 11 Jun 2004 06:44:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYjVa-0004yX-OT for multi6-data@psg.com; Fri, 11 Jun 2004 10:43:38 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYjVZ-0004yE-LM for multi6@ops.ietf.org; Fri, 11 Jun 2004 10:43:38 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5BAh7Lm057838 for ; Fri, 11 Jun 2004 12:43:07 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <30F4C284-BB94-11D8-BDA1-000A95CD987A@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Multi6 From: Iljitsch van Beijnum Subject: identifiers and security Date: Fri, 11 Jun 2004 12:43:35 +0200 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,NO_OBLIGATION autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As I've said before, I think it would be useful to allow for multihoming solutions that add a new identifier space, and also for multihoming solutions that don't. (The new identifier space may or may not be expressible as something that looks like an IPv6 address, but if it is, it's not a routable IPv6 address.) The advantages of not having identifiers are that it's easier to be backward compatible and less new stuff to worry about. The downside is that it's probably prohibitively complex to fully secure any negotiations that are needed for this, and/or it's necessary to rely on the DNS which also has security problems, and isn't always very reliable. The irony of explicit identifiers is that they are so insecure, that they must be protected using strong security, so they effectively become more secure than any identifierless solution. The reason explicit identifiers are insecure to start with is that without a secure mapping mechanism of some sort, a correspondent is unable to determine whether someone claiming to hold an identifier is the legitimate owner of this identifier. In an identifierless solution the routing system provides some level of assurance as obviously packets addressed at the initial locator (that functions as an identifier) make it to the host claiming to hold this locator (assuming a handshake of some sort, such as the TCP one). However, it's sometimes possible for third parties to gain access to a link and claim to hold addresses routed over that link, so this only provides a very basic level of security. However, single homed operation is also insecure in these situations so there is no obligation for any multihoming solution to solve this problem, just to make sure the additional multihoming mechanisms don't add to this problem in a material way. I think it's important to recognize that "regular" IP operation without the benefit of IPsec, TLS or similar authentication and what comes with it (such as SSH) is very often insecure, and in most cases this isn't a problematic situation. So mandating strong security in all situations is probably a mistake. However, IPsec/TLS and the like are in wide use for communication that must remain confidential. In those cases, the key management problem is solved in some way or another. It would be very beneficial to take advantage of this situation and leverage IPsec or TLS mechanisms that are already in operation towards securing multihoming. One way to do this is taking the IPsec or TLS "identifier" and use it as the multihoming identifier. Architecturally this is a nice approach, but in practice it will be hard to get off the ground, especially with TLS as it's not always possible to determine the authenticity of a single packet with TLS. Another approach would be to exchange a session key that's protected using the IPsec or TLS that's already there and protect the multihoming exchanges using this session key. From owner-multi6@ops.ietf.org Fri Jun 11 21:09:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18264 for ; Fri, 11 Jun 2004 21:09:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYx0I-0007aU-BJ for multi6-data@psg.com; Sat, 12 Jun 2004 01:08:14 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYx0H-0007aA-Ac for multi6@ops.ietf.org; Sat, 12 Jun 2004 01:08:13 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i5C16L53014421; Fri, 11 Jun 2004 19:06:22 -0600 (MDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5C184Q24163; Sat, 12 Jun 2004 03:08:05 +0200 (MEST) Date: Fri, 11 Jun 2004 18:08:02 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Sunday's multi6 bar BOF, and Monday's jabbering To: Brian E Carpenter Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <40C70899.6060200@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > For those attending the interim meeting and arriving in Santa Monica > on Sunday, there will be a bar BOF starting at about 17:00 PDT > (OK, 5 p.m.) somewhere in the Loews Beach Hotel. No agenda, no > budget, just an informal discussion for people interested. I hope I can find you when I arrive; I should be at the hotel between 7:30 and 8. Erik From owner-multi6@ops.ietf.org Fri Jun 11 21:13:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18466 for ; Fri, 11 Jun 2004 21:13:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYx5D-000868-1t for multi6-data@psg.com; Sat, 12 Jun 2004 01:13:19 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYx5C-00085u-3l for multi6@ops.ietf.org; Sat, 12 Jun 2004 01:13:18 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5C1D7J6021269; Fri, 11 Jun 2004 18:13:08 -0700 (PDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5C1D5Q24240; Sat, 12 Jun 2004 03:13:05 +0200 (MEST) Date: Fri, 11 Jun 2004 18:13:03 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on draft-nordmark-multi6-threats-01 To: Iljitsch van Beijnum Cc: Erik Nordmark , Multi6 In-Reply-To: "Your message with ID" <771D86ED-BB18-11D8-BDA1-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > We can't let ourselves be constrained by arbitrary features of the > current architecture. If the features are important, sure, we must > support them. But having to do so just because it can be done today > makes has the potential to disqualify very useful multihoming solutions > without good reason. Is there something in section 8 that you think is placing too strong requirements? Erik From owner-multi6@ops.ietf.org Fri Jun 11 21:29:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18812 for ; Fri, 11 Jun 2004 21:29:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYxKA-0009IX-Ir for multi6-data@psg.com; Sat, 12 Jun 2004 01:28:46 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYxK9-0009IK-LY for multi6@ops.ietf.org; Sat, 12 Jun 2004 01:28:45 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5C1SaJ6025753; Fri, 11 Jun 2004 18:28:37 -0700 (PDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5C1SXQ24380; Sat, 12 Jun 2004 03:28:33 +0200 (MEST) Date: Fri, 11 Jun 2004 18:28:30 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Comments on draft-nordmark-multi6-threats-01 To: "Fleischman, Eric" Cc: Erik Nordmark , Christian Huitema , Iljitsch van Beijnum , Multi6 In-Reply-To: "Your message with ID" <5B58696DB20B9140AD20E0685C573A6404FDD549@xch-nw-09.nw.nos.boeing.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Eric, Noel already clarified how the terminology and concepts hang together. Here is my perspective on the last part of your email > BTW: has multi6 actually considered redefining IP addresses to actually > become stack interfaces at the IP layer? If you have, I think that you may > agree with me that most/many of the *node* multihoming problems go away. Most (all?) proposals keep IP addresses as currently defined as names for interfaces; we tend to call these locators. (Some proposals might view the locator as only being one component of the existing IP address.) So IP addresses as we know them don't change from how they are allocated and used in routing etc. The proposals define some new IP layer identifier, and there is a wide range of these (a 128 bit hash of a public key, a shorter hash, a fqdn, a set of locators with any locator being an alias for the set, ...). While the problem statement is about site multihoming, the definitions of the identifier and mechanisms that I've seen can handle identifier->locator relationships where the locators are on the same interface (e.g. with different /48 prefixes) as well as on different interfaces. So at that mechanistic level the proposals handle host multihoming as well as site multihoming. I haven't looked carefully is there are other issues that make solving host multihoming difficult in some proposals. There might be issues around how the identifiers are allocated that might make it hard from an adminstrative or scaling perspective to have a single host connected to e.g. a DSL and a cable ISP, to get a single identifier allocated for itself. I honestly don't know if there is, so this part is speculation. I and Pekka Nikander (and perhaps others) have looked a bit at the feasibility of building a system where a HIP HIT (perhaps with some added internal structure) can be looked up, and I think it is very hard to make this scale even if the scale is limited to sites, and it becomes extremely hard to make such a thing scale to every host in a future Internet. So I don't think we fully understand the scaling issues of the allocation and lookup aspects of the identifiers so clearly say that all the approaches to a solution can scale up to handle host multihoming. But clearly it is desirable to be able to handle host as well as site multihoming. Erik From owner-multi6@ops.ietf.org Fri Jun 11 21:36:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18955 for ; Fri, 11 Jun 2004 21:36:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYxQI-0009t0-Nq for multi6-data@psg.com; Sat, 12 Jun 2004 01:35:06 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYxQH-0009sn-Uy for multi6@ops.ietf.org; Sat, 12 Jun 2004 01:35:06 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5C1YwJ6027557; Fri, 11 Jun 2004 18:34:59 -0700 (PDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5C1YuQ25044; Sat, 12 Jun 2004 03:34:56 +0200 (MEST) Date: Fri, 11 Jun 2004 18:34:54 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: draft-nordmark-multi6-threats-01.txt To: john.loughney@nokia.com Cc: Erik.Nordmark@sun.com, marcelo@it.uc3m.es, multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Well, I think that authenticated at this layer is very difficult. One could > make a case that you could authenticate Santa Claus' IP address but not > Santa himself - what if one of his elves is actually talking to you, Erik? Of course. The names at this layer are some identifier - and many proposals have identifiers that are binary 128 bits. Thus "santa claus" was merely a prettier way than using 9993:8192:56bb:9258:34:99:8192:5882 as the example. So restating my example, a threat might be that an attacker can impersonate 9993:8192:56bb:9258:34:99:8192:5882 at the IP/multi6 layer. But I don't think this impersonation is a means to the end of being able to attack integrity, confidentiality, or availability. Thus to me it doesn't seem to add anything listing "impersonation" at the same level as integrity, confidentiality, and availability. What does make sense is to look at how the ability to cause redirection has an impact on I, C, and A. Erik From owner-multi6@ops.ietf.org Sat Jun 12 21:25:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02738 for ; Sat, 12 Jun 2004 21:25:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZJiC-000MST-Pv for multi6-data@psg.com; Sun, 13 Jun 2004 01:23:04 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZJi8-000MSA-JL for multi6@ops.ietf.org; Sun, 13 Jun 2004 01:23:03 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5D1MtGP095540; Sun, 13 Jun 2004 01:22:55 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5D1MsKM144860; Sun, 13 Jun 2004 03:22:54 +0200 Received: from zurich.ibm.com (sig-9-145-224-243.de.ibm.com [9.145.224.243]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id DAA70688; Sun, 13 Jun 2004 03:22:46 +0200 Message-ID: <40CBAC63.6000800@zurich.ibm.com> Date: Sun, 13 Jun 2004 03:22:43 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Erik Nordmark CC: john.loughney@nokia.com, marcelo@it.uc3m.es, multi6@ops.ietf.org Subject: Re: draft-nordmark-multi6-threats-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>Well, I think that authenticated at this layer is very difficult. One could >>make a case that you could authenticate Santa Claus' IP address but not >>Santa himself - what if one of his elves is actually talking to you, Erik? > > > Of course. The names at this layer are some identifier - and many proposals > have identifiers that are binary 128 bits. Thus "santa claus" was > merely a prettier way than using 9993:8192:56bb:9258:34:99:8192:5882 > as the example. > > So restating my example, a threat might be that an attacker can impersonate > 9993:8192:56bb:9258:34:99:8192:5882 at the IP/multi6 layer. > But I don't think this impersonation is a means to the end of being able > to attack integrity, confidentiality, or availability. > > Thus to me it doesn't seem to add anything listing "impersonation" > at the same level as integrity, confidentiality, and availability. > What does make sense is to look at how the ability to cause redirection > has an impact on I, C, and A. And we certainly should not attempt to solve at network or transport level security issues that can only actually be solved at applications level, where the network and all its characteristics like multihoming are just viewed as a cloud anyway. If Santa Claus lets an elf use his computer, that is not our problem. Brian From owner-multi6@ops.ietf.org Sun Jun 13 00:01:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08987 for ; Sun, 13 Jun 2004 00:01:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZMAG-0008u0-K1 for multi6-data@psg.com; Sun, 13 Jun 2004 04:00:12 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZMAF-0008ti-N6 for multi6@ops.ietf.org; Sun, 13 Jun 2004 04:00:11 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id D25C8140 for ; Sun, 13 Jun 2004 00:00:10 -0400 (EDT) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 13 Jun 2004 00:00:10 -0400 Message-Id: <20040613040010.D25C8140@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 26.83% | 11 | 27.61% | 47954 | erik.nordmark@sun.com 21.95% | 9 | 25.03% | 43467 | brc@zurich.ibm.com 17.07% | 7 | 13.44% | 23333 | iljitsch@muada.com 12.20% | 5 | 13.66% | 23720 | marcelo@it.uc3m.es 4.88% | 2 | 5.14% | 8930 | jari.arkko@piuha.net 4.88% | 2 | 4.67% | 8106 | huitema@windows.microsoft.com 4.88% | 2 | 4.11% | 7133 | john.loughney@nokia.com 2.44% | 1 | 3.10% | 5390 | jnc@mercury.lcs.mit.edu 2.44% | 1 | 1.99% | 3451 | eric.fleischman@boeing.com 2.44% | 1 | 1.26% | 2183 | sra@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 41 |100.00% | 173667 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Sun Jun 13 09:04:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09178 for ; Sun, 13 Jun 2004 09:04:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZUcS-0004CZ-W1 for multi6-data@psg.com; Sun, 13 Jun 2004 13:01:52 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZUcR-0004CH-PD for multi6@ops.ietf.org; Sun, 13 Jun 2004 13:01:52 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5DD1ILm008122; Sun, 13 Jun 2004 15:01:19 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <40CBAC63.6000800@zurich.ibm.com> References: <40CBAC63.6000800@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: draft-nordmark-multi6-threats-01.txt Date: Sun, 13 Jun 2004 06:01:47 -0700 To: Brian E Carpenter X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 12 jun 2004, at 18:22, Brian E Carpenter wrote: >> What does make sense is to look at how the ability to cause >> redirection >> has an impact on I, C, and A. > And we certainly should not attempt to solve at network or transport > level security issues that can only actually be solved at applications > level, where the network and all its characteristics like multihoming > are just viewed as a cloud anyway. If Santa Claus lets an elf use his > computer, that is not our problem. Unfortunately, some of these issues can't be solved in higher layers if lower layers are vulnerable. An example of this is an attack on TCP when TLS is in use. Since TLS sits on top of TCP, it can't improve on availability (in the presence of an attack) over regular TCP. It can only guarantee the integrity and confidentiality of communication that actually makes it through. Alternatively, IPsec rejects falsified packets before TCP sees them so it also improves availability. From owner-multi6@ops.ietf.org Sun Jun 13 09:07:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09275 for ; Sun, 13 Jun 2004 09:07:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZUhO-0004ia-Tl for multi6-data@psg.com; Sun, 13 Jun 2004 13:06:58 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZUhO-0004iI-1T for multi6@ops.ietf.org; Sun, 13 Jun 2004 13:06:58 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5DD6PLm008200; Sun, 13 Jun 2004 15:06:26 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8AB9BA1F-BD3A-11D8-8ED0-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: Comments on draft-nordmark-multi6-threats-01 Date: Sun, 13 Jun 2004 06:06:54 -0700 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 11 jun 2004, at 18:13, Erik Nordmark wrote: >> We can't let ourselves be constrained by arbitrary features of the >> current architecture. If the features are important, sure, we must >> support them. But having to do so just because it can be done today >> makes has the potential to disqualify very useful multihoming >> solutions >> without good reason. > Is there something in section 8 that you think is placing too strong > requirements? Since it uses the word "could" I don't think there is a requirement here at all, so I have no problem with it. Also, I think Brian is right in saying that site multihoming and anonimity have a low correlation. From owner-multi6@ops.ietf.org Sun Jun 13 12:26:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21976 for ; Sun, 13 Jun 2004 12:26:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZXlb-000NVc-O5 for multi6-data@psg.com; Sun, 13 Jun 2004 16:23:31 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZXlY-000NVI-MV for multi6@ops.ietf.org; Sun, 13 Jun 2004 16:23:30 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 90BB539DE2; Sun, 13 Jun 2004 18:23:27 +0200 (CEST) Received: from [163.117.252.249] (vpn-252-249.uc3m.es [163.117.252.249]) by smtp01.uc3m.es (Postfix) with ESMTP id E847A39D83; Sun, 13 Jun 2004 18:23:25 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <353F1876-BD55-11D8-B0F4-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Multi6 List From: marcelo bagnulo braun Subject: Re: draft-nordmark-multi6-threats-01.txt Date: Sun, 13 Jun 2004 18:17:47 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Erik, sorry for the delay El 10/06/2004, a las 14:53, Erik Nordmark escribi=F3: > > Thanks for the comments. > >> Section 1 - Introduction >> >> "These attacks pose threats against confidentiality, >> integrity, and availability." >> >> I guess that i could make sense to also include impersonation attacks >> (or the way you prefer to call them) in which the attacker pretneds = to >> be one party of the communication, since they are also considered in >> the doc > > I think such attacks are and end to accomplish threats against the=20 > above. > For instance, I might be successful in convincing somebody that I am > Santa Claus, but if they are not going to engage Santa in some way > that has no effect. Well, if i think i am communicating with Santa and he makes some=20 promises to me, i will believe them and expect some presents later > If they do believe that they are having confidential > communication with Santa Claus but they are instead communicating > (with confidentiality) with me then there was an attack on=20 > confidentiality. But even if it is a non confidential communication, if i think that i=20 am communicating with santa, but i am communicating with someone else,=20= this is a problem > But perhaps "authenticity" should be added to the above list? I think so. > >> later on it states that: >> >> "This document has been developed while considering multihoming >> solutions architected around a separation of network identity and >> network location." >> >> I think that the threats are actually related to the fact that the = the >> 128 by string used by the routing system to forward the packet = differs >> from the 128 bit string that the ULP sees as identifying the other = end >> of the communication. It doesn't really have to be a split in the = most >> strict sense (where an identifier cannot be a locator) and the = threats >> are then also valid by solutions that use regular addresses both as >> locators and identifiers (as you mention later) > > Agreed. But I don't see anything in the quoted text that says = something > about there being a new name space for identifiers. I agree, and i know what you meant, only that sometimes i have the=20 feeling that some folks don't consider mip or noid as a loc/od split=20 type of solution while the threats apply to these type of solution too. > So how would you propose to make that text more clear that a new > name space isn't assumed? > > How about I make it say: > This document has been developed while considering multihoming=20 > solutions > architected around a separation of network identity and network=20 > location, > whether or not this separation implies the introduction of a new and > separate identifier name space. imho this would be better > >> Section 2 >> >> "identifier - an IP layer identifier for an IP layer endpoint >> (stack name in [NSRG]). The transport endpoint is a >> function of the transport protocol and would >> typically include the IP identifier plus a port >> number." >> >> Is there a "name" or an "identifier" missing after transport=20 >> endpoint?, >> i mean would be that the transport endpoint name is a function.... > > Yes, it reads better with that added. I hope we don't have to > argue whether it should be "transport name" or "transport identifier". > I'll put a "name" in there. > imho "name" is fine >> Section 3.1. application assumptions. >> >> I guess that another assumption made by the receiving end of a >> communication is that the initiator can be reached at the source >> address included in the initiating packet, since the responder will >> send reply packets to it. So i guess that some amount of trust is >> putted in the source address. > > Yes, but I think this assumption is more fundamental than being just=20= > about > trust. Do you think I should add something about it? > No, no, this was just a comment about the issue being discussed [...] > >> Section 4.4. Accepting Packets from Unknown Locators >> >> I fail to see the threat presented in this section. I think it is a >> relevant issue to discuss whether a solution should or not accept >> packets from unverified source locators, but i don't see the threat = of >> doing it. I do understand that threats apprear when sending traffic = to >> an unverified locator, and i also see the threats that appear if when >> accepting an unverified locator, some action is taken, like changing >> the locator used to reach the other end, but if none of this happens,=20= >> i >> don't see any threat here. > > The key sentence is: "In the current Internet, an attacker can't=20 > inject > packets with arbitrary source addresses into a session if there is=20= > ingress > filtering present," The threat in general is accepting packets (such=20= > as TCP > RST packets) which can cause DoS and/or corruption of the application=20= > data > stream. When there is no ingress filtering in the network, this is=20 > something > that the endpoints need to sort out themselves. However, deploying > ingress filtering (or source address filtering in general) > helps in today's Internet. > This section tries to state the concerns that perhaps we want ingress=20= > filtering > to help even when a multihoming solution is deployed. > > Do you have suggestions on how to make this more clear? > Ok, it is clear to me now. The RST example was helpful for me, perhaps=20= adding it may help others. > >> Section 5. GRANULARITY OF REDIRECTION >> >> "Discussion: Perhaps the key issue is not about the=20 >> granularity, >> but about the lifetime of the state that is created?" >> >> imho is about the different scopes of the binding between the = multiple >> locators and the identifier used >> when a per connection solution is used, the scope of the binding >> information is limited to that particular connection, both in time = and >> communication sense. This means that if the attacker manages to=20 >> corrupt >> that binding information, the attack will only affect the scope of = the >> binding. It will not affect future communication, but it won't = neither >> affect simultaneous communication with the same peer (like for=20 >> instance >> in the other direction) >> >> So imho time frames is just one aspect of the problem, and = granularity >> seems more general or scopes if you prefer > > Yes, but this section, which is subject to discussion and by no means=20= > is > finished, tries to point out that by making the scope smaller by=20 > applying > the redirection to only one connection, Well, imho, this section discusses more issues than this one. In the first paragraph this point is discussed. In the second and third paragraphs, another issue is discussed, related=20= to the direction of the communication. imho these are different issues. For instance, you can think a solution where each connection is handled=20= independently, and has its own security, So attackers have to redirect=20= each connection independently, no matter the direction the connection=20 is established. Examples of this are solutions that make TCP to support=20= multiple addresses per connection. Next, you have solutions that explicitly handle different directions of=20= communication separately. This means that all incoming communications=20 from a given endpoint share the same set of locators, and an attack=20 will affect established and future incoming communication evenly. the=20 same for outgoing communications. I guess that an example of this would=20= be wimp. This makes sense, imho because as you mention in the draft,=20 the initiator role and the responder role are different in terms of=20 identity requirement. In many cases the identity of the initiator is=20 not very important, the only relevant issue is that it remains the same=20= that had initiated the communication. OTOH, the receiver identity is=20 always important since the initiator wants to communicate with a=20 certain host. Finally, some solutions handle all the communications together,=20 incoming and outgoing. Such solutions (like noid, sim) require heavier=20= security features in all communications, since no matter whether the=20 communication requires identity validation or not, this feature is=20 provided That is why i see that the issue to be about the scope of the binding=20 information. We need some security mechanisms to negotiate the binding between a set=20= of locators and the identifier used by ULP The point is the scope of this binding. This binding can affect only a a given communication this binding can affect all the incoming (or outgoing) communications this binding can affect all the communications with a given endpoint. As the binding affects more communications, the security required for=20 the mechanism to set up the binding would be stronger, imho > we would be making more work > for the legitimate applications (such as short-lived http connections) > as well as attackers, and the ratio by which we make things harder=20 > seems to > be the same for the legitimate guys and the attackers. > That doesn't seem like a good approach to improving security. For=20 > security > you want things (like keys on the front door of a house) that are > a little bit inconvinient for the legimate parties, but make it=20 > significantly > harder for an attacker. Well, i guess you can see it this way. The other way of seeing it is that as the the risk is higher, you need=20= more security. so, when only a single connection is at stake, you require less=20 security than when all the communications, present and future, incoming=20= and outgoing communications are at stake > > The "time" aspect of the scope seems to be closer to this; leaving > any multihoming state around after it is no longer used by the ULP > might not provide much benefits for the legimate users but leaves > a door open that makes it easier for attackers to do premediated=20 > attacks. > i think this is a good point. When considering per connection solutions, the time is naturally=20 limited to the lifetime of the connection. The problem is when you=20 attempt to use the binding information for more than a single=20 connection (or when the mechanism resides in a layer that has no=20 knowledge of the connections) In this case, you need a garbage=20 collection mechanisms, to delete the bindings that are no longer being=20= used. As you mention, the presence of this information when it is no=20 longer needed for the communication is a liability, and would make=20 sense to delete asap However, i am not sure this is strictly related to the point discussed=20= above. Perhaps this is a general issue? >> >> Appendix B >> >> "However, the mechanisms for addressing the latter issue can be=20= >> quite >> different. One way to prevent premeditated redirection is to=20 >> simply >> not introduce a new identifier name space but instead rely on >> existing name space(s) as in [NOID]; in this case premeditated >> redirection is as easy or as hard as redirecting an IP address >> today." >> >> I am not sure that i agree with this. imho NOID prevents identity >> hijacking because there is a trusted third party that informs about=20= >> the >> acceptable locator set, and not because there is not a new id space. > > You're right. It is the re-use of the existing name space *and*=20 > presumed > security mechanisms associated with the looking up of objects in that > name space that is important. > >> For instance suppose that an attacker have managed to induce some = fake >> noid state inside a host B , so that a given IP address IPA has an >> alternative locator IPX > > And it can do this, in the case of NOID, by attacking the DNS. > > >> later on, it is mentioned that: >> >> "In some cases it >> is also possible to avoid the problem by having (one end of the >> communication) use ephemeral identifiers as in [WIMP]." >> >> Well, in wimp the responding end does have an identity (the hash of=20= >> the >> FQDN) which can be hijacked, if the attacker manages to introduce = some >> fake state binding this identity to a fake locator. IMHO wimp avoids >> this by using a trusted third party to create the initial state (the >> DNS as in noid) > > Yes, for the responding end. > The interesting thing I tried to bring out is that for the > end that has the ephemeral ID, you can skirt around the premediated > attacks (assuming the solution has a robust way to pick a new ID when > one is in use/stolen). Yes and the cool thing is that the node that has an ephemeral id does=20 no need a stable one when he is acting as an initiator, so providing it=20= to him would require additional security without any benefits (which=20 doesn't seems a reasonable tradeoff :-) > >> I see three ways to prove the identity ownership: >> >> - a trusted third party, which states that a given identity is >> reachable at a given set of locators, so the endpoint reached at one=20= >> of >> this locators is the owner of the identity >> >> - CBIDs as disused in the draft >> >> - and a static binding, as currently defined in IP, where you trust >> that the routing system will deliver the packets to the owner of the >> locator, and since the locator and the identity are one, you prove >> identity ownership as a subproduct. > > Agreed. And we also have the option to think about ephemeral IDs where=20= > they > make sense. But imho in the case of ephemeral ids, you are not really proving id=20 ownership, because the identity is meaningless! So you don't really have to prove id ownership because it is irrelevant The important point in this scenario is that the the communication is=20 always with the same endpoint. In other words, the responding endpoint doesn't care who he is=20 communicating with, as long as it remains being the same. So, i am not sure that we can talk about identity ownership poof in=20 this case... > >> Later on, the analysis finishes with >> >> "Finally, preventing third party DoS attacks is conceptually=20 >> simpler; >> it would suffice to somehow verify that the peer is indeed=20 >> reachable >> at the new locator before sending a large number of packets to=20 >> that >> locator." >> >> I think that there are some attacks directed to the identity role and >> others directed to the locator role. >> I see communication hijacking, like the threats presented in section >> 4.1 as threats related to the identity role, where the attacker >> pretends to be victim and take his place. In this case, i think that >> basically the identity is stolen >> OTOH, i see flooding attacks as attacks addressed to the locator = role. >> The attacker pretends to own the victims locator (not the victims >> identity) >> >> So in order to avoid the full set of threats, you need mechanisms to >> prove the identity ownership, and also the locator ownership, so you >> can avoid that an attacker steals any of them > > I think proving locator ownership (e.g. by verifying using DNSsec=20 > through > ip6.arpa that the locator has indeed been assigned to the node in > question) is one way to prevent 3rd party DoS. But it might be=20 > stronger than > we need. Another approach is just to have the peer identity show that=20= > it > is present at the claimed locator, which is weaker (and how weak > depends on how the details of the mechanism by which it would show=20 > this). > My point is that the latter approach doesn't talk about locator=20 > ownership > at all. > >> As i mentioned above, i see these three ways of proving the identity >> ownership, but t prove locator ownership, i can only see two: >> >> - trusted third party >> - return routability > > I think you are overextending the "ownership" term when you apply > it to return routability; I think this is more about "presence" > at the locator. And there can be very different strength proofs of > presence, from just responding "yes, it's me" to having CGA/CBID > based proofs that the entity at that locator holds the private key. > Ok, i agree that i should be more precise about this point. Perhaps the important issue in this case is that a given endpoint is=20 authorized to use a given locator (i think G. Montenegro used this=20 expression about locators a while ago) So we need to provide identity ownership proofs and locator usage=20 authorization proofs in order to make this work So, assuming the above taxonomy of means to provide identity ownership=20= proof, the mechanisms to provide locator usage authorization proof=20 would be: - return routability: i.e. if an endpoint is capable of receiving=20 packets at a given locator, it is because he is authorized to do so - third trusted party: a third party establishes that a given identity=20= is authorized to use a given set of locators (for instance the DNS) > But it is very good that we are starting to discuss the initial = attempt > to capture these aspects in the appendix; understanding this helps > comparing different possible approaches. > agree. regards, marcelo > Erik > > From owner-multi6@ops.ietf.org Sun Jun 13 12:45:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22616 for ; Sun, 13 Jun 2004 12:45:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZY5s-000PI7-Ou for multi6-data@psg.com; Sun, 13 Jun 2004 16:44:28 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZY5r-000PHp-75 for multi6@ops.ietf.org; Sun, 13 Jun 2004 16:44:27 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5DGiKfV032510; Sun, 13 Jun 2004 16:44:20 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5DGiJr2278680; Sun, 13 Jun 2004 18:44:20 +0200 Received: from zurich.ibm.com (sig-9-145-170-82.de.ibm.com [9.145.170.82]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id SAA62064; Sun, 13 Jun 2004 18:44:18 +0200 Message-ID: <40CC845F.40008@zurich.ibm.com> Date: Sun, 13 Jun 2004 18:44:15 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 Subject: Re: draft-nordmark-multi6-threats-01.txt References: <40CBAC63.6000800@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 12 jun 2004, at 18:22, Brian E Carpenter wrote: > >>> What does make sense is to look at how the ability to cause redirection >>> has an impact on I, C, and A. > > >> And we certainly should not attempt to solve at network or transport >> level security issues that can only actually be solved at applications >> level, where the network and all its characteristics like multihoming >> are just viewed as a cloud anyway. If Santa Claus lets an elf use his >> computer, that is not our problem. > > > Unfortunately, some of these issues can't be solved in higher layers if > lower layers are vulnerable. An example of this is an attack on TCP when > TLS is in use. Since TLS sits on top of TCP, it can't improve on > availability (in the presence of an attack) over regular TCP. It can > only guarantee the integrity and confidentiality of communication that > actually makes it through. Alternatively, IPsec rejects falsified > packets before TCP sees them so it also improves availability. Indeed, and if I had written "highly available cloud" instead of just "cloud" my point would have been clearer. We do need to worry about availability and therefore about attacks that reduce availability. Brian From owner-multi6@ops.ietf.org Sun Jun 13 19:13:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10354 for ; Sun, 13 Jun 2004 19:13:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZe84-000DFO-7u for multi6-data@psg.com; Sun, 13 Jun 2004 23:11:08 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZe83-000DF8-5r for multi6@ops.ietf.org; Sun, 13 Jun 2004 23:11:07 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5DNA0Ln018190; Mon, 14 Jun 2004 01:10:34 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: Sunday's multi6 bar BOF, and Monday's jabbering Date: Sun, 13 Jun 2004 16:10:41 -0700 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 11 jun 2004, at 18:08, Erik Nordmark wrote: >> For those attending the interim meeting and arriving in Santa Monica >> on Sunday, there will be a bar BOF starting at about 17:00 PDT >> (OK, 5 p.m.) somewhere in the Loews Beach Hotel. No agenda, no >> budget, just an informal discussion for people interested. > I hope I can find you when I arrive; I should be at the hotel between > 7:30 and 8. Yes, some location information would be helpful... If there's room we may want to sit outside on the terrace that's some steps below the poolside area. And how about tomorrow? From owner-multi6@ops.ietf.org Mon Jun 14 09:51:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02556 for ; Mon, 14 Jun 2004 09:51:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZrpr-00044h-Op for multi6-data@psg.com; Mon, 14 Jun 2004 13:49:15 +0000 Received: from [193.136.195.3] (helo=gab54-1.org) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BZrpn-00043z-V2 for multi6@ops.ietf.org; Mon, 14 Jun 2004 13:49:15 +0000 Date: Mon, 14 Jun 2004 14:55:14 +0000 To: "Multi" From: "Kurtis" Subject: Re: Yahoo! Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------dnqsclnrfehsljbredil" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,BAYES_44, HTML_IMAGE_ONLY_02,HTML_MESSAGE,MIME_HTML_ONLY,RAZOR2_CF_RANGE_51_100, RAZOR2_CHECK autolearn=no version=2.63 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk ----------dnqsclnrfehsljbredil Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
Archive password:

----------dnqsclnrfehsljbredil Content-Type: image/bmp; name="cdomdvnrhz.bmp" Content-Disposition: attachment; filename="cdomdvnrhz.bmp" Content-ID: Content-Transfer-Encoding: base64 Qk32BwAAAAAAADYAAAAoAAAAPgAAABAAAAABABAAAAAAAMAHAAAAAAAAAAAAAAAAAAAAAAAA /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3/dc5VHKgNwJ7hX/3//f91zcjMqA3Iz22f/f/9//3+3UyoD KgO3U/9//3//f7dTKgMqA7dT/3//f3AnKgMqAyoDKgMqA/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/lUcqA91z2mMqA7hX/3+2SyoD 3XPaYyoD3G//f7dTKgPaY9trKgO3U/9/t1MqA9pj22sqA7dT/3+3UyoD2mP/f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9/KgNwJ/9//3//f/9//38qA7ZL/38qAyoD/3//fyoDKgP/fyoDKgP/f/9/KgMqA/9/ /XcqA3An3XP/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//fyoDKgP/f/9//3//f/9/KgNwJ/9/cCcqA/9//38qAyoD /39wJyoD/3//fyoDKgP/f/9/2mMqA3An/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/2mMqA7ZL/3//f5VHKgOVR3Iz KgP/f7hXKgPba9tnKgO4V/9/uFcqA9tr22cqA7hX/3//f/9/lUcqA5VH/3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//39yMyoD cjP/f/9/tksqA9tr3G8qAyoD/3//f3IzKgMqAyoD/Xf/f/9/cjMqAyoDKgP9d/9//3//f/9/ cjMqA9pj/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3+5XyoDtkv/fyoDKgP/f/9/KgMqA/9/tksqA9xv3G8qA7dT/3+2SyoD 3G/cbyoDt1P/f/9//3//f9xvKgNwJ/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38qAyoD/38qAyoD/3//fyoDlUf/fyoD KgP/f/9/KgMqA/9/KgMqA/9//38qAyoD/3//f/9//3//fyoDKgP/f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f7ZLKgPdc9xvKgOVR/9/ t1MqA9xv2mMqA7lf/3+VRyoD3G/cbyoDlUf/f5VHKgPcb9xvKgOVR/9/cjMqA91z3XMqA7dT /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3/dc7ZLKgMqA7ZL/3//f/9/t1MqA3AnuFf/f/9/3XO2SyoDKgO2S/13/3/dc7ZLKgMqA7ZL /Xf/f91zlD8qAyoDt1P/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fw== ----------dnqsclnrfehsljbredil Content-Type: application/octet-stream; name="Your_complaint.zip" Content-Disposition: attachment; filename="Your_complaint.zip" Content-Transfer-Encoding: base64 UEsDBAoAAQAIAIB0zjAk0r1b/lYAAHhTAAAKAAAAbXBtbGh5LmV4ZReFoSLeU2xGO30MQS8K lTrEn5GOCaTv/fUhIkgYuGxNVcL6XlUwM9nfAMjVohBNJ+vYW6foHDpqfelBeNS+9X8sDP5B 1WOSOIvLH7FgsS1BRzL95/g2hMPWzZ4USyCcerC+eJfCfdvdpIRpxAZZqv0LAo+0I91NynqA TTwZBkAb49vdKBpYafl9E7Mi695xGSMNeW32OzP/RHeeWVEzhz9mOFKJywF9u79LsVlKZAXr TJq1eU7bTMNKD3ue/GBF8iM+0CmYnzDrlr1Wlc8sZSIcd9pMJWhE8hcxlHn5GE/EJAeOj5z5 bT3yY92vaoZjiQLzc5vbCZMapLvoXqhd6a3/D7REUF4J0Qd8BRfM2W3Yp1W9roPJYwyQ2IHH CyvMowKN9rAjLU3hO2ogZMHXoQQMPZHvbJMrq6O+/Csau6Yb8g1HbUfoOWaUFy9+RDsSZGlu dPlIwcpQz/6OWTRTdNYnjlQMADsqrL4S/hnNeQbeU0DsPq1WttGv8WTpPIOJ42SWUJ7OzjMj xi/0p0fh0XEW53xsmG6XXAJQpqls6iwZCISDa970l249iFeQyzgZgZY7hE+2N30N3q//Y6Ep wOJhoQTLMfycqUMIp4dclDfIvmNchf8BOfKUDNIFFhoC8+Zn8M0ZCkItWC2a0HL4ogwcT8US AsQTulEMAabq2gPTesGsxkZDR6IHfh0uLagTUlqdapvdRe4plpmO5f7GkJm+I/RUkb8+mdsD ZVjyFl7zsdaQbB56u7EvOmyNsoR5wMXFt+EqWMEoB8jToGSZOsHLpgeJXymkqUl+E5ihJB3+ 7CtyNMXeoRcgAcUjhPOXSv7Uyi547oL0+v4RlD91eGb9SinmLQZP+OFcr8/0Q6cSiKhWxrXN V+kfU8lCYZWSE600MhIBRLYsUrmisflF7U5x8daJHiXNgzpYP2hkAK2+Eq7rEfFm4IGg1FJH uPJ1MI3JPbU9CZ8ZFmT0WojHp9WQDbMSEcSLFxA8ModtVIxCbUcAIxcKc6tORtRZ4gzxl45R d7Ns77q5gGWIeBDgcmsZ1ZS8q6UXe+GUfYegeQmoiguOxJCQh3LYhBLlHHbrG6ugshTOMYyK BJeBti5Xtr0BsCffHCStSvgJ9jT7iYPinK7RwgS8onBf0zKkmnRTsj8zaYsXKJElrkPDL15q IGRIr4wJzxY6kVlRFfguhwqWpZMfziulBHQ6mNtOeAQ3hZcwjrr7m1XH3aXUYC6SwPcLK0Ee deQKn+dn1kOvHCJBXr7yfQHAyci/SeF/r/MEmqhIviFDh6Jz3uIqx4FN62hlqrZjEdMAdDMJ ytdqf8u0zz/euu9zzV0R+KeHT8NHpcOHC49gPLrF22Tnej+35rv/P7iTD80qzH6EzqsIid6h oNqXku1JTdiZkwkQRkpWPbBb4SVqbZBaWMmm/7kEsOcDGO7pyvoesGXV/BrLcXtEPo0QKDLD FZ6Z1QzxztBW4Qs+X8sWGFZxhcAUeNuvArJLk//74IgZYBTFr7FJ36rED4SZfbVFqqYAv6id LgCsKzmXqfEwRBm667eg1R8B5SLgI1LFGrXLFoKTLfhtrBvur2X54Z3LGI+SNuJobatTCNYj 4aaY8u2+WGvAL1rn7RaGfyxy4/AIbTMsTG2jBY1OV38VX7Wm23b9n/OYwWAp6z+/X0J9B6U1 qtCxtIfplEYgI78oRlYZSEWz54oQcWSPprDJb1tUJXLG8ATfGkBaooTiMzQ+DqH9ZXcvFYJp 812vkFkgD4l19C6amyVNADit/YYJg2D/Jae+QSfZY/Rjk8+ws59CJRPt3y+zy+P8ZBjfR1kC cs6j1HxxRfR5WdHmdb9B5z/u5x5cT2LmuyaW6Bqq3WVmxLwIxZiN5OSmfZ3ZKIgpG2CYxZtE VjDROT6nob/kcMccw57T3dEOhcbT3SFe2o40aW8fsX4PutTBj+f+gX5FNYe44g+3JoROFaqR 72/z5oBeDXj572d2MBsUtruqgJ/GK4bHnQm8ZUCMfNZYQ/FSBSReD0XrlNfj53xXiNoxHVv0 M768DChXyhZTmZsD4yJbTwHSTpxe4k9DZEML+piW+8nVkT5baZzd+JhYtv8XymJZtGgCBkHq VBNy7O4synw+lC3VUBEtp4MnLs4LEe5q7ygMl9qp/8shkeomVxwU5yEkVR404Zy1+1Pp2snQ NDUtIQ01zOLwygmrfrwyhx7g6t6B9zdLcPyK+t82yAs0LuXBrqXmSmPXFnypurv9lfU6MCph 88/ljFH0z3SjoY3eDDzCsAaNHC5AlQ/W2jNfBoHeIvMG9EhgrlCEfGVQsp8kej0at/PBMTGt UBdmAnO5T7mca+v6/YRHSFTEYHpWYG3GMmHXp0xWfSLtik9+9GD32uPFu5ZkIpxGN9PI6sjP KnYGhoYqhGl09txdiKo637UTRBZX+DycNWo2wKgCA07NMjeyh9cbtH1za6fM0cbiNkPrketT Agv+B3pZjfsL5fmVU2z6L+6FpQZUfqXQjFQw6jDd7AN4I2b25J1wyB13WxZg2i80a1PeUt5C vxXRDhYrIvMVxcDr9lzK5aGHZUzo0fUuIZNFoyx9idvNHhX9vPTk7U8fS7SGS5BZdSdzHC4G TUlq/JmwDKdoXlaXTPqn/XuA9hMyBlxRh19DSYXpCsnGFiuvsm24zpUsYJGlWQRvYRkmWkvM 8fZKOHMKas4YMpBr993UuBHZ5ehdq4xenWmbmEM3AP3WE8IocfpfgZzALArcZG+eH9zedJQm Ey2aXPpJqSsuHswIq2wORCpA7GTunAVRGdDDaVF2yTGNofpwIQCYthy7X1WNAU6eQWf1aoiu OUdlbVt6jxqIxaXXaJuNcfbAbUQfTQz1xoL30yXEC8VAtY0JWbegFysrzHIi2hS8+tDQwwHp SuHasBq9CNgWZca3v/MHFzzuaJgwMRHzESMtaBgzytuobOCZ+vwZG+D3dHUj0ElSCGB8mXGa LFgnFa1wu3fIuYIKHXO/+Ov2ySmiWJVmGLSK/DKlKzl/6ntFXEfzp19oJAG+8VOymqLD3mdV ZZv5SxJY4lrWxdIMvWA0W21iE6ysbUtJCazQ6gyZ1iVG3geQ2EhcoCMjYtevpYUmM9maflCp SGaug7wRdbuXhfceZts/sc/jmTa9X4UrR0RDrR4UDXf9cZgB1izDoPDfsUWaAbauskW1QpZx 7bU170ut+Zk1pgqkLeJhC/VBu1oxEMgqlR2YRIfhlru98nMQDH3YT4fzdwhtVKv/jPdJe7Do Qs3l1jsJcs0N1Lt3yrz/+eA/u73fw+juCJB0J1wk8AvnmA1tv55UBpYZdXbEzWrLQG7q04jc 428RG726d/fdP3IqgwjBKT2MrrgGN8pvObHzjixNmaN6mlZJUcOlAyQrSdzAiCpZe5b/fBgQ +RBWyEdgdu2s1H7pNaCRrd49KAyLLdMytbxRFJESPrXS5hvevzCf0mpnt9vnZ4q483ny1kyP u07sNRAdBC+ralhTSz7KCyZoZ305n8EjdJwR6BfbekzWCaTdVeEQm3aNd/T394wGDVQoa8oG 663HRBKmu1HRnTk05DdmVDDjUFIrz8c7wKXmtMiD8gep74NzvP+khRQi5PiKLtpgA3E5Ien6 yvIOfcrgyWAZW8cil70YN7jS2K1yVpUnhph6HKWLVrAm1Jx25dbvT3Ee7z3Zc2qhHHXfIve1 FiqnFqZrsJzoz6qNj6lAB1QYvXsb0Bw+hX7pSAYgfPN9zO/f1bA24/w9YGa3IezvnRKMSSOI ugoJQedSQTrcpj4jWSaQR0s8TG50eRXGyvWuDk3qUikvxWyQqS8KvckmstNgZVgb1CeI3pzd B6cs20ZaKHlm1fMXUREdKmxJ6S7WL6FitgEfdCaeamrEOFE7P65a10phDw2nX37vblCsWdmx WJtd8vub007zd6eJBGHYDhjupHo6mDE0a2UWIRWSJGlHgHKbqGAAkpimHIfdOkJ2+6zhZ+hc YuqdDaMI/4UN9g9+XHiy0tGUBGsQFldrs/3Htx65SZdoyC6S29fg9aUh4ZH9jyAFNeIM5M+E UAkzbPYK8xH6yGMS1WfT2L4WHBxttGNZdQNzhbpzcqt8KNeaVHnbMD3ZT4147NZZWy34FnyA PMmPM602SLXCuuTqDpCS/z8pyEzqW45BP1N2+p0QEyEr3ed3VhhTYAx/I6rNN40Iwt8vmfH2 dbJesIY4R/qA18gB5unx3w0opo4Jxfd+wbj+gRehohbNlbvZHA3BtOXkJNwszZ+6R7juVdnr WH/yt9+cK/m4PRPn2IW6NLXmzeoM7vF35O3TNrdaRKHbLmFrsC+5qfqqD43Oso3qWSvPGL5V uAb7o1EqkEFmIibHx0U642o8cnLlkFGNPgNnlOTRsQw9Wl7ke0m8RnwIFsYOM3FSHVxCxOho EQN8RU3VM1jH8+VHhXDcrXAw2LJ+cKvWKAWOlNXgIFelVmo/vzAwVDIE+2Q/wOuu9Tt5LLEl O9qRw8hLpMebXyC7ztSQsoLfCRIcXhoipQcB8WZjsRhhgZRU1zZpPUAhr5yN89dr3y8NlFOO zbqx/+ukC/tBC4qgWLO9XpApUNZ9VozpqQugrik8wggP/znLzbfsPoubuJ1HITcE719M2BJF K7wCtjtvG+oNA0bK1LdybAnMfsQ884RRC8W9iqO9yQsg9g3NhrFfnkyuZRsyeDy2wPDYZ1Gp X68ZWNxVzpuaDJpP0jl80DXC7QcFnviOsLRI11J1I0d4C2CIczhLWAXk9SrPKQgqrVef0cPC WAWeNM2VvRMZS3DuIlBnRBtCKtqi20B+n414B8Rbbj2CwSnnpetrb6ECUVGBxrd+2Bt7xv4c yW4CpeiqlWs5iVjO/2PqA8g9nyDOa0BA9RW9Gy0Q9WDMTWcio542k8+BbZ16rVcotm+LFHwF PE8UkxEUlPiM0cEbzoj2huIPh0r3NsabrzWFXiMT5ReXJiCCITThgxqgAFQ/ER8qxTiXt4KO hPfy7E+zZjVsHhrNHgHPD5WqiRBnPKrg1o8FlcIG5rmlW2sLobDPLVxesdPqT3HWpuuRg3yD ittdZyLXa26/71JeMWDqASWbX8wISdvSiQQTENVWLIixC5FQ97W+XA839cqZlu2TXg7fflgW B6rfIVYs0QWTpE+T52GivF0GFw7Z78yYbmiGHLsxlt5XcgYkAL4WjLaSXFNFEoQm7tdD8xJb CtUutuLxcL1xoDatxQ8M2JwUhF0a70PnzMyrQQxo6QpoAN1t4ndDNisKArT09ic8YOGu68fN dS6nfZoAjgYXjOKB9uJWxVCc3N2K2JAjfGdeY5U+78zdkLerWMJlcGmyQmkCEWhj3xF6Tofl ojKiBdw+30RYoMoKdTM84VsiTfMGK6S7hu54x4fr9nLuZKDV0by4Rt6+AjoHJl5ReyRGCvQc mqNItfw7zUvybnIZw4vmi65CLkDvwN4qinE/3F13JtlPR6mVZHTWk5iu+7jDfDoos2ApnwJD zfkSgu5KaKAslaqGFmFKfqr+tpB4MauJon9X9aIKU/GTB9TFGXnrpxAkpvIoCdM/4Pkmzwvt 52oG5Sw05mI4sudKITA1spIaHeIZqQ4MnvK/z2q8ni4twJgvKA2kqIk4CZqO7Mwl/k5o0Pw/ kXFJeJBoPO2pVGegje+Ipjf6HVIazA72hj8aFrsAftPqt2l9BMVXGPNntycRHbhMVr9IyoFA vwB5gkuvFruHP8FrO/nDi7ZpWnLBER4PvolzdhcgNhd3br7YANT3a7qyLAd45lVeO0Q0kV3H psBYb4ig5V7nKO+3Y4mPhmhymSldG6ADnoShTSjjGhwTD61sAbiqaB30smP1lRDfXvV9wqsT /aapYmMq2mWKRONxMVAMjxixwLYBo7+YmZjEfNTx9D2Sgxc+H34rmSkHxYcv32JPqVV4YHGw wRjNWgdcYgk4lAil6l9Zle6ys3nWpGrgsCN3y7QSj1gTHqGGNGEq/ibAfpQPC3E2jqWEPDVB gQ3HOvBNfzm3Xker/2avyiTjfLL+0FytzPPa7L7vgDRYzDFmFk6qkQ1GrBbyX4Tc81ivkTtT Ei3nG6i+bqLKU/e6Oa+Y9qFQCa52r3gjw4aKTBu4Rdd6DpdSk3M+QHtSoNMYr3tPDAiYikvq TaapQtC6KZqL05UDzC+r5/bvKnpjKA8o/eLJe2Ehf7F154cKkYJ0qicWnVgqXpppvNthI2Sv jZvUmsAAWxtMFeUeqNAsjPfO1sW6WnVnV9FPf7YFS6AVlS2gsRaOlT/+Qr7y1nIAfvbga+QB Zg46Vw8Zxy6He9zi9NHu0Fcv7LTXd7AImFepjD0i2b/RiqWHIu2wq2zpamkVuzQnZfrn4LWI QcTB16XcGTJNLz3nbhm9GvEQSg58xDks1kKMCf7HbDhhs0sGFzQTZZ9NM4c0XCK4l9CyCwmK vjDAWf4/Lg02m7fCtDBnP4SbXE8W5TPbjS6FnoUPuVgr2YoZLZZLStHXs7h40GaU/ZCIBlAU RKMMgZRBMGQT/1yYIYpEyRDauknyVCHpV2E2WD7lOszeri7fc1Fxh7Od4G77SBnUybIL0C3n Ptkc1Vigevgtx1Jwt4QsCmEXBOkroG2PYYwpDNhk5N2XcGDJIHFpGMNozdvRlPQW6TZjTwjo T/XddWrLxLRsFZkw3miaiu7m95EzxCA2zJKILqna6oWklSEvUSQbh/fpO2T6oBm8+9HcQAvF W7Gk9NwqERc5Ayfriti0JAasQZGZ9Q4pxxLYPGcwdeYyENEizGSIQbTnkB4yRRNLm5F//Q53 H+ClGCh4yFSb3hEk/7d2Z1sjgmyxXKtwi3omsUaw6+ja3081xai4LtdTz3iArbr1PMH5Ozrq jd5n+R2xSRqpkxsmPBJe1HVGcOK7DfDJ3o/UJueyFPzkxrvEG3RHfyTq3WP5SLeLOiBwVeuU jTS1fAqYGNRySdLxOeiw+AErv1nOSpdL0YwLp8B8FUP6chajO3gbjYVsyC0MX+Ufv21iudjR cF02Je+tULQwVaGG2LEuYOwqEXN639NQYiLlCyGkL4/c883GErpEdqv8VSMqGH4X39mZdMoe gayTh0ebsigd8c4GHUWk+NVn22HpH70w0ZQF22PkxdtkSoFvGkCLv/yjlghBWFonz5skDaIl YzETNTTK34HkDohx6iC1LnD61QYPl0hcwi/6a+znl3yu4y5N+ZQxe7YNfSYP1BF8oJdqCtYH +TJtBtEG4uuo3tPmFVpeqwf94rhGxboIU4K8U6Sj6C/splicibc57TCJmoeDKsQRrgm15cem c9BmNGdYPbR7VQDAlX90yErp5CNI3jo3lDF6bYXAlEuK7VsgPJwQ3HADUMXzGmBBc0PZc0Wy 6ljBlibMoqS3trOp9RSSO3mxV+YvowDgdihXZsLnLgvKOSL4/BOzoL/iBHluVxu6FUK0u29A SxgMFTNuJv4pYd9zJorTQqHJ0a9XyU5mwd4phO4W+iDpoUFdpVnEcsxX4LIhcdZ3ED6DvlY0 fnydywjqbVK3dXxLOi71MUIW7tt2f4N0NwHmGeldPc671jhEr42feL1BiEqxgaXZnzQPLUkB FBwQBKJlNHV6/jk60YWrQV93sVCnforG7qIoiFV3v777/pv8/lTd64fGN9Zsj291qbPXvfDm XPEZB2TX0Tp1w69+h4w61S+Z48uptFY4mlSa/PBkjQAfSHgcKfDwotkAlKwQfPZSM5m9ua1j 2+DbXNRgrG4RXye5ZmwBd9opGW+Hxl2VnWgfsMmF/jZ1SQZmGBDZLuyoEZXqImXNDUiGq7SQ 1IF3lJ0yI6nO3picStx+BZGlagE4thdizDzR7+MQ07jIQI5M/GH2tXTEJPxrr9RJ33Mb+stN 8GVcvVD1kD6rBWO0/DbsRyum3DJCZcqHcPHvWXMJvalUgbM+cWI0KkOzN0/3z1ZPEew2Wc8u BBQtVTSv09bTqjeQnbluS4Y28VHR1dClA+bWalmfdpdug5AJrg+NKpQTVL79KRrc2FjfSGu4 P5Zb0THp3ckctbMpqytHYKHkJjbw4v45h1CB5LIOswNx0sYrq/9KwX4U363b1a/acVZZ6OIm byo7SDlHiTD0C5d4/i3EjBCcSmCFqUhOQfN4kplvF3p1Vov3eZLtWAgylEmwAxSA1XT0fvyT iJvuWBNFSNHKEDYSonUBzmKgo9KuNIfbauv2ang5hFZqccYek24k7utyQWUPCN0THUDmI3el Vsvb6MokRzcpoTKosi3yTup+V1CdDUopL7+lCzSAblJp871Ydyw5nvx9OsaH5BpMkGVOHcwR tm9X7mf4gaAuA/7i2s4SU0oHBiQQQZQCiwH2Nrtc0THbDIZf2LUHQyyTK3LXEhsMPDd9qEJw 31XJhPYjNiRlbu3fLvloZoeq1PcgBLRf5s8ZAhKazGL38IVcZoICVyPISfmh7SXkPns7msSr OPLPvnE20UPXDHZ4dzvZVBFKLitHD6bqGZeV7NtUQ6Xn21R4985LXG+YX4g6fiA8zffOjtcx jwfRtzzJk+Ti2Gd9eAvqYeeXa0ey+xwRGc5+mbKXV/J9g4no/7iwWlxPGvot3g1+t4vipE6R WpFZ+d7VUkEx4Z0rgJ2Q4cJqZEQmHLCAwEM+ioTFnScHXls1DbLvuYKQR47H+T5ZMFu8W2Tm W/5xdJIFMRAuwCXxd+kRTEJBdTQThcEiLWQGMGZsa1tyOtVlJF/QKMXI+d2rwm9+JDgEnmJ4 WzdQfnC+/kCgcKA/rXgriemEhs0Ez4KEDkkmiHaaDSqzZNnmHqMVIkchQvuNmk6F68+WgwZI bPl827d0JP+dRuTqeVCEqxnJSD2NI85U0VCc/WjlldOltLIOeFvv63grhSjOkPI+nJK7sOS1 VVhZobaPnaQVzCViJ/H9vVOMth0IDRqWVFarrx9nVXMwniei/RWp59u5zcS4Xq7w/+LvBnqb WkXpCBX+uU4tnchMWOYWci+gLa87xrj4/kZveQA8vdQcmFYPQ0NKMY6Sx/D8aZzXRFIQty30 s+2mrnC9L14e2NtaL1Lj0T4uuEKfsA+sd/GUIr5OcqxSdnyq3zZ25FskBL7BJyzZ6Ulb2627 ihZABYarXv7eWAdXvMX7eR6oQ4Sovclbk9sqvdEDdbWQGHJpIYzSOrSbvpu0VCyyoJ2TZC7B MLtI6zChDLT+EMWUpJVvMZXCCQoNW11a83hVmUBMncqRASU3v7xNjfTRcpKLVk3JBScowBb8 pWlkxq0CHt0PuxLaY9oQZSf9w+ftdhSHgOyRnPbIzTgLncVquA3MywPX2P3VmIDIhaaymE5c 7X3pVzXcPgY5ACWqiPWT6fsd/jorKiNRE1o7A9rt6MEbOq8RHzZx347SpIzICu4cAQP4EiEP 5ZrUsegKR/dU/vlpGABae9y9CGznz7MN1o+NJhzujZ5M0or7bjXoQPs+Mcovax0ZNXBd985Y TPIq7iYGlahsYLcUngFjn15ynTDAVnSXRPfpRh1aTQj7xa698z4Imq6t+08nVcvkTEw6le9p IJ3B/wWZXEaHbU7tjb8X+xlZ/p3sJ2hzEU0esXPwd/f5alZRA6IRUzm3vA3miDwPEG/jhXHG Prd0I2qv+j7+BEqBhs1no7PPy/+Pm6qEFAgltUdaNjM5rRCs+wi3MuJRjmyAe9/3/zzqOOd4 s4cdmfdALHCOw0oVd4DUSADk3Fp9833aCM8XBNPGczHz/rLmhkGB4WdIMfLWhdMm5MRLRo8G DoVDgrCZU98Nnq9zYOYG7VcFuKfI2bXFineHexDrRxfMPjarwVlx8gZi+UxbChVsL0D7fwSp Zr7FvNDt89t1dmRadip3gLYz5YGCIAKT43dq8aklEt8noMp5N5YFdfPbaFsu2OjL+EzCtX14 ZCOuXq4ofipvOVcWIRUOiNC0XuMStj5PgA4C9PHpcgEm7umvHVMZb5L2bhYadRq59jnjlvf8 cL50Cb1exF5ueaVOh3GhuO94SdgCvQ0CmXtJOKrJxQRUeFt+0yLTbfRWykVgNF+KC1KkkNQW lwVN4AOchwve0miNNU2KJ34A0sjNd4QmeBhzdlUVYdvWkzoEjvXL0bhx/RJ4kpOFANifFuUH GXgwsO7pnU8XQoqg1bGB5bTI6AAUNzv29KysiZFcxvaZJ078pUJfTtsvYcagifY/zNhdfb2/ u0mcUYMGG69xcIAa6wXfUopj1OSmWJkWDCwg8PLjFjpxe6OZmaHx1EKsgOB2Uy03Z/GiR4pb 5u4+hDnZJy5pV3NOoz41LNWI9mF2NNcS4BRsxzbYyCjxlCb9OHZG/Ad6TTNPQJBNDmslXZuq slHxWloXmpsLA+JMr8WTXqSfpEVlXqWzSd5WXirkoPL2HAgYIvwz6VDrL88QQPGmNMvpS0/1 h3gK4fCJaAoVPdsmcbmk6S3TAORT0JG5Zp3CjsMc93eOdHX0+/sBtHrvZvZvaX/IbPt/iIdA 5nZ7r4YMh1S5dvQPRp1O5msOsL639kq3slaZdHHgbEi4vNa6q6T6dZsUW6MF8viumvfETzsf rjnyPXAWA/xI6Y3K+7+b2TlxU5g1FDzkV/qKBJEWM8OEMcQid6mDPQrkSTiCoSecr9Cm3t7Z EI0oSUQ7u8ttow4qETigYvJZ+Fp0jJS5ayfYdlO/QMSFmXLeyhhSYJgrf9LXo5MF14bIuzri SVI4rytD6jefFuOhXtpm1YMmtoIMW8kx9dfO4duw2gN/BqAvUom5/dFiDq3J6MNl/34jpl4V RR2oc7uiWWVMvY0mJaQvzIR2eQA0+gxoB53ut4U22Nx6udQqF1B7+caKjU3YkJ8l0YpAeYUW KyylMWfgvBwj36v83dXwp90DNETKdTKiNlR/vFp5jJGrZsHzMKqOpZZLTSh4A8sQq1OCI81i 2iEDGSInW+GupocFe0xa9Gw/149mfMfVL+izpLUDKwnykLQ7/1RIDWgkWVJd+2by5gLhGm3b oHXxrfMHN18uoKdRx/xHByIEarf/rhXay5Zz18UW/alLx/T4sHs0K+S9whBBp6CtnSZeuvNZ rqgjNA1tsfFbzMteqsI1tYHITeSeIJk1r4GxGqx0GpRO7XMmHOtHquvJQlUV3fgjMNtgdXbj YImtUfGne/633aa76OPuhfGMdNgNpuZ8Kqh9jyCfQG/FVmTzBtgJ1GJx7iqG/jchFPWECfUt JgfDrss7GZ78mEKAMDm4pTIf9OwpDLNG9H88AeF12UjztquEFzRCMpwWLbLr9/FzkppFfoK1 soIiGDW7ErGBAjmxzxk8cvaAufGmMuxdhlkFwderwAkfbY8Jr3wCKx9m1osMKqSJ+yEv2XZE wM9owNBWGHeeaWuDxmkKBBAiKSpQcSbHEivNrQofUB/5D//61G08BBAgiP5itbBe6JJfUksA avqJSP32wp6fTUgb3xgbXmvRgNXeLSO/n5hhvMBObZEVzkiEhdcdNpQ1tt5WGPaZqxUBZxqY GGO3O2lBbBfsC9i3q8C8qQtUggT6w7xOzTvOPrMulSWDncM4FbKWgAMAD2cqrJW0bYoLp87u JPYTvw1nHBff/PHKpsvS7lQmZJlzbdu57SVU9XZLFemCzDto4qSsyIdCoGFF66rDIptbv7pQ gNCy3CiaFn9NsxWHCBut12Avs6yghoNQt5jEFhmA7RGNv5c+aNwTMHxsWY2GUGhJcG8GCzXq ecNw0m4JTmA0rZIuqmNHGEom9DqHwHa35AMFVU0FAuqx7U4x8QISSEDdGLZfPP7wX50sbaXI BE3EA7Ucee4RG3+1KInGG6Yg4cEnmIXH0kzCWg4TZljyRRGtv4qLsYTwJn5uYz9C8CLKpgJx elLz37xzvib8x2TZUCg9GP1oHvF7oLcpGusM2TrfU+yGuoXQP2IYkRmy//vO00HK6UjPSFzi KuP5LyWEyEAsQGipVMcTjns/XYhfx8itS2kphps6E6hIM93Pa42GUXwlG+hlUOFaz8SzSH8C vuHczcv8hg9VfKMvUpt/PgWY+CDowvlREmSV1fYvzeu8DBaNqdhmcQeaKyKFBw+P6ioHk8Re GGZpd1GJHOHsBwddA1Ujk+jiM/S8/gMDAVLNLIuGBQywKdMZu763ZsaNSc/uOnXJbl3s1NrL 9pvI34kTP6opGC+TmaY8gKTbgC+yGhKuOuVA57y55E7suxfEsPLxdq4vkc6zoLepCKB6BNWZ x1GjEzjmmvS18ySdXVRjz9n5KKFIunVbpTecRd16Pp05bXHmNK4UoosfmohEvsObV8KgmI5D O5F+rCOTrJnaLgoDYWl9OkxP9zBKVU7mWyQfb3+UGlXcetE8wPlywgSf7oP6WuHh60Fdi/vi pUEQowJ3rJtTN07gUSUrF6mj9bkShbytEAvxknlY4oUBgF9XiEY9Z9cvNLFUtcJtNjDirqEb 48ldYIDEuNrh+PVLl6CCofpVnmoVQGXs2xV2aKynWQzjENvAZU8ZnTHxJPeY+AAZpswFXEF/ 0MQ3xeOg0MbINnARefdWPu3u9RV2qVGAiSe+RMPFEszeI5k6WKsXYE1rwpbhmqqCMk2msJ8S cFKA1xTNxXtUSnVNrDsZ4k+XXlOqNIk5u0c7hVEN5EXy3N0S3mJlDfDGBWS2iDZOgKrkY1oZ tqrYQ6mg9kbLHGfL1PkXwKiViTxGfufLPhseuDDEMYelpSKmuqWG3OvjnT7btacgJAWjwYQ0 +CWDpglnYrmKe0vjygM4QDQncKkyZ5SAVBltQh3XSClXMfdcH04EHrv5kqoxk8Y8WVMZom6r qN3Ady+OFU/i2UjVPLdi6MDPoT4/oOw05tWqs8eix8aifAkNBtKfkrBfs/A4wTG0WHB9/l9U 5/bpCFTcafRXCGj05bYlMNhPeyEKuDqAJm4iLICpK3GhJ2tdGm+TdVidyMVsol7CfsqzlXPP 06Axg/sPX/VRd4NP5KccPU3EAAHOcd1rvMbV5axfwQ0wRzcSBpUsvpk8iFR4ipPLkbYsus4f Xy6XsoSFIfl5R8H5P9rdWKtbeKl4l8rOVnJ+KUl/mG/9OknSwUQQOfD+2NUvm3vYd9WhJVVI 5zDNLACJCK7cMdmZyEbOY20780W09iB3DacuRveSujf5SZZLhzKvlIkQJinIIF21S/5hpn7J y5zwyGtFyJXUVkCYRtZn+WsAYaxxGQ7YUNbI2GLJNHDL1H7oCz9SIGuDdYAJHr9/JSbUDf2Y HKryJTInJeJvVYw/aeyooMdTX7Ajyhiv9Tbc9RkUgf1WxoSw87PKJZPGNk2EBUlyOZ7aZJQ6 IXnhH1GcKRmNFbxKLeyleSj+dHaCqAwYYdMrpbK8DVMPA1BBliJ8q032LH8bo6vGr9XC9PZv qfDZUX9Fb9JgqtG518Gymk3af0oRbMC7adKVZjj4kXcNNucdYN6CY5JLb1NS9XWBBodR7J18 DaQyhFPY+zyJhQhsBPBf4PN7OQnxD5RtiirW0sNFZTDjDsSRIjYQd0k9XcmFo0oXKCx5OMl6 s+/8ylUg2LBKH1wwOuPuOfanaP5gF5OQsG6PWKySw/Ocacws5+prRkAR6+5Ye9D6/WaaxunJ k4jllQ0NzCkUsi8qnsoL3c4OJNQq1aBC2zT9TkNz0SfbKpWgbvQBuhSJpwDIMKiL4yKdraI6 PozsRIqBmiMGqrUbXDcBn6//2pfNlwTNotVyGSRng3r/kKVGw1jfzq8IfgY8F5h7tAcx6dKG 8to7IF/eKmYuUJupfruLqoqsd84/VmPZPs5QR/A9K3ChJz3vebOTsX2KWMri9QB8XjFMrx8N RuGSYzUFPbBoLB6ztLlbXfjBkydr7F5Y/MypUIJuq34AmVmf4W5bx45kvgryXMMjV/ZKVIb8 qih5nxwL/8zP6WrnvyD0FtmDP3o76/g/NZQfcEUQrKUvI3ZA1lhFPg+ASTaOpprPJDD/ymA6 lBQCHNDH/LW9gL632DezSedO+g0YjSQhEbsBYI6/Nu+J00yguXfTwcR0bKSxOL/4ADOo8zs7 70fl+kNuT8GO7I4OfqwJxU7fngfOkPJ6yXgtNXyzI7ph9PJ+JzP0D3DZbJVP6VLt9JYwKHS9 oeBUoo1MILq8BNyz9WnZ7ee/6rHfj29BUY1QGrCTtFzW0b09KOE25XWLS91RA6a5rMhq/njC SMI3v0GJI9exi5yLUKofSPINX5/st7OKHLu7GR4xZWUuYnAaW6df/0izhUpcvvCVxmOOm+2E 8lCQrJpaLbcNWkPtxKwqtVbzP1+b+AKHjysfS2A4AfJjl0q9Zn37/sqM06Ktmey5H5CHqkj9 CNf4Mn3Rz6GrDeIlJ080ekPtLHEj2RMH3M3Bf81xYGkPRIa4w62gGP/MSumW7QdE50eXSHVc NSahViFo2EMrcIH+4n+TnHO6vYqLM1homgBr4PRODCYMjS5/OEOjff39e9RM+dVzjU0fG969 bfvcM+iShx1icpnetwl4jl6xroUgw+UnDHwUBpFsWLzZ4mdkvu2C1Y+rP9v+GtUIhwAhhHU9 JKvpc23HCx7WEMabp2cYAlLdBWHaiGN/GEXlY9Z4IsaDMiAE8xBMx/+DduqjeIn+5ssWBFum MGqN0T5ja778lfPY7vOKTwFoledG2rwRH8n55yjyFvZSGn4IGBlL7RfZ8wLWxOSp+VE+U+Gq 1qwEyUR/uojvPcHxmX1/a16Ylmddkajw6hhH11HwJFEwcC4VVgxm7JvbsutX7UFUSCzkEZVo UQIoAPQTzKk53M2xpsWqznt0mR6Pue1Gi4XHXcI18P0vJN/gzj/QCePTKeh2j4aUEqGMdMES xOO08RulfNUVfnw91y/l/nsAAIwz94itAIakNTMYtx3kIvqLlLtAXVR2WJWO+x6b64LWVD/r sv+2o4szW4/GaSNSDV2P/yDH6ayJfukVKdIVOQOVl/iVW/P2d3QR1SGQC983RFWDVZLFC6aX 1vV+IfuKbwOuns42wf6cMfwIUNenycqVOVVR9a1mwhlW0QpBw3iegF3yPG9Ry6fw3z3d7H24 OdDZWZKL/uUVX8NxK3TSfhlsz1ryaZkWvr18iAgABYbVK3vH1dhcIKTWWjBaWs43rZznjJ7+ KxUU00x43nAuTPyroYSjhQwBQUq2fCfAu9/3NagGCvE2N59EOzgBmbfX4fYL9Z3VAmlPf8WD C7uS+QFMDIThOJwwaimzPtJm2ABoKI7J9of0JsJ4H4YhQp9RfIsWvv/8SO82AkLyFQ+VvJ6Q hMiTvTzKjc7b4h8KjQ+EwL8oCCg94f4+O7unGeTP5et7wroRQ041NpgXyoJ0RatnYtI4BFaX CKtkq8jJJcaVjh1JXqntd8yAeIL931lfRPHBLRwdMNTji0gW7JaBi7EVmtxo88peY4pQ7LGQ pmzLWLj8SHxGsEZr/8m32boGLOT8RFhElvqbXN6iN3NyVC9+L7c0mfjPhTc/0MRUKpIaoGMr blB1Nikx8R/qkcCrVJ21XRHtD9ij1NyYyzurpt7OCI5mxl3rBg3Htg9iiUAwqF0edTo6ZBUs b+6ga/Cynmp0bwphfZIQtFbMjyj0XjjyvtGAoA8+BxC9r83o93PfjWBR9U3E/iFVE06fEPij dl968Hh33JXcxpYHTY1qTh1pGdhSSDcL+yCSpJ+JWixlNl06unZ6TgZ61CWbEKTWjouvtVTQ DNsQcc6rCBGv7kU3SRP83Sus/kDDR6hkBTOdUXyQ2jr0nvQ8Kzcf5jagnB7S5H0WBXFnjyPL 8U2DAUv8WrdYUgmV4LGXkFXrInncjW5kabXk3FNPPa/whVjKhWuGHEQE04C/vYd279kJsmYM E0kQCO+fe2DPm22YCvIZERLbk9x21k9x6xPImK+OKNAvWJrl11b1vohagN//3xycuV5zW9cm THWr03ZJxl0Gu1JBGGtfTJGLv+8/HxBas9E6UMXKGN+wKo3ehZCaTJL80NYfjzQGFgcCeWcg X1Ha4+qsHgVoKncqxVMiEYDT+DeauYsjTxTzfHlvlgNoBpEv7jSArGHAZ3oJX4swApU3VCGw yJk1PKiHSggdbE5i4Jg8veJ/4w2IBbdxISE7e38BJpJ4NhHAG6Y8sY7A9NfpyHO0Swo/sxAu m12BfdCvU0wu09zLpu4J8XtMRmZdXQR/DpTSsn6lwF7gTUz8/YrAoCUYMBFwVvE/e38mVmwd DYqfyEM24TzdZGmbXrn5GPn4N4uAN3HInFIzqRKpU/a78ij7SkRtPIApU61Wu+JJ+62xWGTT /WPV+6A0mLehJa0LQMDKbh5dFhdpA5bB5AwZK26IVwkeb2xD2TFmLsE6Fmg2AZyNFUWQQ2HK 8JbJznsx0DBSQGpR7yTtYO12oAjmx04EYwypqyXygppc06kNFZxfx01cycyTXNl1MfEy2R/w /vvKU6vSqpCCK06f32XU6ldzu5kpNbWMDKcXlVvCvx6RJDfAwZYpqegKhIAuNkehw3dt0Gtg U/c0aQlrK1NDchiTgfSZJxqEyfpNhvPacUGcLFhhuPbCNdMEyd8+Xuz0bsfZ9RuUc7sPpHzW dvcxuhYK2sd4q1oW7WH/KrzrmLSqoMMMpLOnYg2k2m4d253lh4J/NZGLWDH2Bg9XdkkdklRP dbrmyJKVdKdvuyNO4HY796CWqVZ0mLCUsaIbw6gUhY3ftQ7iMcU/2xfZk7+KFa07Y8qcHLUR SJviOq+fFhBam5MG1sPjDjzdrJsk4ZLw9qmYG53WsIRYJbwN8/lQXZcPY5lCnTPDrN7tf0xD JVIdFXMj6aInvQ1cnuxtY1uValcjvTJWg/Wss8dVXvqyQkE7vnZMy3GMAuKwrVZNYL/lNC89 eE69uvOokaLplOXUMd7DjbbyV7Z8x4dCyfiJtYd821RK1lo3sBHrjsWcBQNoIJeKvyTBaxXU 52zC/gwcIoxPPjHVGCzNgBSuJZP8PTOaTAexD67oR2NxjsPEtrPqiSZJAVwyOy8FDx2tMWA5 2lu8BMkoxr6lFlvfUXX9uGTN9r4yrTQ7mN5qFon3t6wVgkFE4YHp/6y+gRE90PW5xTPx3owN Htd4uXjTv+3Z845XPt2zOWOdmqwq4kpBUrmskwzPrMEvS0cbqzPTDHTiHuxAXfQ/KLVEOqyp H+rtNMNOySGTDIDXAFhOFSMXbVVo0TVF4Nn/y9Nhx3PYosOLkWDcLlbylg8ON87ToSVdO7Rm 3+WGeu1RFOxNWH0phYstBpklVR+MxhoegIxuk6+Kakitfu5gxb/QZltw1/1QFegPCVDYzw5L sxc6aXAIsf61kFD2AoB1QJDOcN9Et9kIjPNl2kSe/uW8/60eGxnb/SId2s8xJ6qDMJnWX2vA bpjrok5P/exw7Q6VLD86MsCUgILbGKpQirfFCSYI9dgVOEgQfGnRO3v5uvOvKdVkKbAnrGSy sRwsv5zY64eoC3bVJMmeGlcD5JXkfry9BJ3uZqsJouM0uMjuugrt7ZFplYP2lv21Cn0A7Vym zp//bf7sQsBXD6mVGCaLBtEsKgUuEv4Oepnxfnh6qBlH2/Tdb6Rq+4fFBy2HY917YOgahYAe wtR9F7p0Yc5gU+9JLu6/TOVgG5WKxobB1MTbDkyLddJe0tNTmJiFVPF4vqdaoiU2YW7/qseF XY7hmGsfrjNt5TtRqYjGib8nqa260Lg8bmSYDVXK5Zd54GGRKPuIQeovyUch77p4J9MAjJVf 11MPBjcSNwDmlqKb8DCft89C/sXNGrrI94FLHy4HfkU2cjB9rIDcKcwUJBrwzYPIARWuKIRa l6aGdPgRPdtUwQ14ivu8u3HrPKxN/fA0rYYCQK+CbJbHf7T7v6weGVbC4X/MVTfzlNVxRc9E uCYuIPsex2eyuqk8YQ1/g7poqtV1l+TBfKx90fOxYecnxHe/r/O6nrl65VfH6kssgh9+GiD6 vUGuId6u5Xi2doNatNw/x3H4yc5H53k5r8DPioNhJWTqVb318oXxwIRppjgBreMtwxBXyW0B GEB7BrZxqgudkbSbtx10Ox7+3AT3rsfJA4bX+eoyzgziAVxOQSvgmDMIPF7uIZEmXcw4bKvs e9y04nTMRondxdInzWB2zAtoJA3VtoLxV4C7KcwOMOj7pPLDF4raQaWZMJCFAkfYVyEkStF6 GFt3cfaFGcvduLKSSTJEL+afCQmE7uqQRyxa4/YM6l/4kcqakfHyzXTYycpFaMFX5j5bJ/dh LV0fD0o6G89nUleNRRBm8s0P5BzmR4FuhT9ZZbJlQBp5Ynv9zdaHlJbkHf8VBgBIkZXlkR87 EXMN6OQsenBJO+39fU3gSD211fIKquDfrhRZw8nvZUDKnHxUv9aJffoSlOFxZ97hNzvZiHs8 jp8AuF9YCOP+fsfnx6/lZnjhViJVdUccl0EOexzIiT6E/nYUIoqn9D12neExnaMDysyqS1S7 r4jCoh3U+nlBjWbM5+n25HsNfzgezcvIShvMJ0Gs8zVchVSCZVH9uYMt8M1EtJ4gKGMH3Byl HQs8yJjOuixI5M5cH/8ty/qGdq7ShORAiWnggE4n8BYj3rlV4dAUKMLPoD/Y5TgXmEkfDu9r Fc+83YxzlI/BB8MzGVc4RxnNEdvK8xy9cOaTlOnDYbbs4Tt2t1yAQtKHGLeGs5o8rwYPjhsv GFW5rDwrzTS9q2A54aYCJs6Pew5mrsVrc8fYI9sOQIPG/FSets990xnltPpFJK+3R+6PLaRa AI2+mASj3FDAWiDts9cou5kQpY6akFxfibUG7J224vwI8XuvqvsHiXG8Z12r/C/20H0eXus3 6MtZRlILJVmsyXGS9gqPhZs7lQGFgHFkTVCpDfBq74T+zOniY77+5H6hc0oBsnN64xbuSsTi z5JaUgdF5Nhqw6P1vcaUML2XbKVWU7Ns2ZUFeaA6YekcRDK1qSB93uyhYmQq2BNaR3iepguO 6/yytW8BrAWS+I9W51SScLHjwPUQj6SPK+3zCbSD0LsqWlRTPWqfBjkDWaQPbMozV69YQ905 zRes5vGkJa+DRiqHKaz9lfKDaa77+hlZ8JedsQZ0/i0ppzQT1VlemMeViwClW+SgVzzDDhGM bM//AT7VDjFnJLQbAvp1eo1HECHqmk7VTLLMwuAp2XL3SEygdbrz3yLHzJbxJX3xrPP00ya9 OM1amSh6qi7N099L1XZjKnW61ZbUoA0XqnA9GgufL/VS+evzVxWtD7AiTsd0xkT2GXo4hTdo ufIinukr1d4UKaMamVTkfc7a4DFhfk+w/tJVpe7UQ7FNIN87rl12QEx+3aXhhww7JzU4bx5H qOSivH85o3YEcPIgDPumAnPvLcBtCe15j9LRmV97yjr2Xb35/KxgwlrLc0u+7wrF8XewHoYQ Iy3ewnwmpo8qnsIaWphRhSZJHZUZklcLQkwV72HeWISS2h8hwyjFAU2yKQLVuom6jX0SKISb cunNKxiuUUzsRfOpHRfDRMnKnCvNKbfrEtJgeXam0KFZzQkFT8Jm9+dCvHvRlqxPq8wuEkYu Bll4DcmvxAU5LPxHs9/HG9LGxT0rrwdj31d4Qve3b/RPkZ8KmHn/11nn8s/8tBF+I0sPMfP9 2gGRnHr088EUTztFh+VYNP3fKJpE2zJa08BVPBBX8ewvh/wyrD305a9ez1gY/0hbQXjbp1fj UR1s4hYfj/n/X0w1uMMw8vyhfl/7nIMhGIXsBVDsy2YrnSnSQO4wQy8As/7TX8s1aM43PA+J PdNP4VimRsE5quz9cP6W73RlUtVM8+1NnSiWmHx2WItdXaPlMij2SCggu9UaSMIxLzrxULV3 k34ASVCWwCH64a15akqXfwRbdUUqJ7D1mwLhNTzNbiKRibSVNqks0hZEpaxgCyv2BPi5SbSA Ul2sHGMy5sb6G722/Jb/YxnvX0Mysfuhm8vyEhIaR/KQceWer6xDMWQqGzZ5J/yNc7hLA7uK S0j2IVz7C1zg6Ip9oVaq31NZlJbAvODdWLd/vqyIcpN3ftFO5/KxufZBhyO54OsCRHxSNmMS rRg/8gze4+yXvKVA0dBVvxBxp1QKSckRAckEVuuNWjY1oGvPkeEY0uRlMuFUuCXdWV2ITb/2 mpry+DFhsJWOWdw0AJKrVkoCdO9eWdMBQGndj9z+qXgRc0AYbLzn/68pBOltuvP3YVh2jWK0 JvwIkwYgQN4DBX38hjkzclva4dTkyTjlKxjcMPINeXXzg6OCnp6yn6CD96glgmk6S71OEeRP x5oDSNpjLQUPQFd3zJLwQmhQNhy/yMnZOKRiiNVPvl/3pxn/NPe1SqpMshUws/94lJcJtXh2 89WgPY1RnNQ/9fMTh5EiUhDulZhhDst19Mu1g3yNmjx0ZQZQdwPxUgC/vlVSe6cnPxrMDh/O uEDgBXqnUwpXb6oX7MUvK3XGTJvkvwzzWtR6xDmS/LrIs03z64TxKl2fZHGY+PE3h0Md6lnN AgO9SoFX4DdrzKRt7KtPqetIHCH0uGcmrJAHQfghjQExtfzTAL79t9DRHQG0XPLjIaJhWwLh wVfJd7nrL0dJR0Hpr5HWjwcb5J/UTaz60YGNJSHxxpcv850f1bw4/4sXUCTFf17yqgjqSYdP 0WwkpaCdgaWBbGCvtQhTZv7WL3eHRC/23UzdBrg2IVjbJDeee9YRRfjltDg43H3t2SyJcPkq I5dKrXQlWoUNKhPyWOloEUApKRXOduZlHsuK9XXfw+FDXlUTySbGlgDF8jpmMwB0jm3U0y/S FFCnDxmj8lMK5UY2NP0XUPkB+S0xk6o0eG+JxKDvGN/uBteaM4QsGL7hbX67hEVIa+9yvcGS vjTtT0sBvEfAAdu0l6CPk0uWQsYRDgxqjqVxNBUAob6aaMisFri93iqGrKOmoH++655Iui4U bFIvmEUZYp1rWlQqwQd30gczqqmzUms1TLtdb062Fm3tGTy047bK0ePwhAdaYEawMyR6v9Da PSzAF/WoySP450TFisDCnU2+RYfoUOiHYCIxYGtoPalHkormjln6N7FLP4CBjtczNk0RTjN4 cXjVOKLBUZNF7dHAEA73Exgu/QJC5+E0UUwh7lJWR2X1E1PyVxCdzsPSguhJ6lNypSCnPoBO T6N5JkJfHRSMkicJxHYQ4bD55RY0ixAEwreRVQ1JukhgwJ2zQfidvU2cNfU4wN127e0hihFB 9XWGgxWwNvP6oba7XaDlkAZmLJAcMk2B5wPnsgUQ6d8aKiQGpaPLrTvTJAJIdCdXuqeiB+bz nHQbaVduWHI4f/8hu4I5JJQqfudxBfELkcFFyMKrlqyMh2SyJR3oXWnSBEcNHeyKGlph/dlq EdkJbxRo0CfybN8V3lg6go/0IcWmX24CM4n4iRVF3Tn18Wnh/ssXbiS7/ThaCfPJhMA5mTgW Xtl5tkgI8qW4LskG5vH4Xq9NSt+Ru3cDzaCo7e9HKpo0Q+NJVHGos10j/m5rU5nRY9bd9n4q xJ4M08QuMb2JJ59lTCKjoAT2jDdyszqg+3QovgRg6OiDv9WVZuUE3aYZgSpx8xtLm4sWj26q t9du1X+pA9QvAKQQzpW0T+R5q1vqawEjJh0YE9b4KHDW4/VCDuq0DNPdQgMAa7G/wjk3cJaa WJo9D8jJrPdX/hKFR6gWrJ/A/ig/CkzpkxB99heFArhQgyhskMZZrJJSrjtnxldGkQelFljM vn4gello8P7YKCjb3+hVGu1Mb+F5Pkm5zv2rxg+F94SBdoEg+D9FlB5dxUlBumqLtI2RgCtf 6he6gSgHOO2L4zE3xeY9j9wir4Pf5u22I9cHtPL52W557t1RXJDvwuqfqZpLYeGuiMIgO9hj VvnLxidQChHuxcVoKZdy62pZCk8Jy/rl9rJmbdzVYMFRwyfmST8e8dLorr+3L6sl4zzQk+Ml e3V/A0pkcTsHbVRToE8iF4/Rxt9AvHZNMLjjkDuINPecWyiCOVXdpuHSBW1uvINfcObwyDd1 fF2548Hya/CJW2DiS3rtmFQizi4Cn2xSp9iBhqcSx1etbfb9z3p+MaAaAXNIfJczKjWEz+8Q w+kqN82l8FfS9PEyZ6BTktjq7OhFJKR47zwznkR3gUDB1ioYpo7crNqKCj/wIEypU6OEqYoq zxPDBC/dDvLwEmb5qQhAKark84JXbkayir4z0RHEO12NmoyXZrgtSrHvjMDg/YWkaHgyU/wB VDGGPtff0+Ans2jTAR3vgNKlDV6Z6O30e56menOtsI4g2ao0wLc0DYrxS9o7glDy2MZprc7C ae+8lM/MCZeRFgqdpkaObWbyYDbuGMOxihzoObr7gzPN6tJOyj/gR6lRbtMGec5eBUw+x7Tj Fg2492Nb7l8St3bjcfJSa8R9GM20DXVSrJiCAy4HUbQtgtnhUu8M2VDFNMaUl3URkn+UmzeT fj7QWpjee4zAMe1mv1/iT8UGsr81ZBuQdGxCGlA7IwpJmxQFgtR3X8F4s5X6egKQK22Khwc2 cT5W+itMRoOhQt49ym1XZwAcMVFkt2/7wSI0I+4OWz/spqt66SST9ydIEZfuajhlkUAHvLCj pXBTl/MycwE+Fz+V8hPvgVA4RbktFhQniPc9M4zJq52HNsPSSUgxxDDiTrJIJrPtyGMCEMhr tF5d0E/7JDN0F5BCNTrVGCrGNZGfsUlDRF3Kw6BrvFL1CNkt8zB0dgbf402AiC9O0naMmtRj o/zIAExH8DVLih8fkI2zz4anq1VA6SMNnuB7kJnd/9U1uR+/N+Fk6tLUQfV6jNRjUCedzcEN 01pJ7AAlDVwy+HbnpgX3j/Mypt7MTQHGBuNtCQsxbgk7CSewKfrDcb6oUWc40HA7Wl2SgQ0l uXMULCcu2146Asg9khE38CNBnur8Ib3Um4fm/T46V1gNIybX5152f+GzAHdys+lyiqGpPolI G2cZggoCcjhp9pdEPcmdL4o9PxRWHVbp1TwsmkKh9mJZR2u7GLI7QhsU3K3aekEDOylliCMg 5m4sqB0aLUGaelI5QQOrXpSh9U9HtREmuaxy7nxrHcx2OaDNoVgaXXJ0sllbgSZD8wsaFq7H n3aZC0oflzjEUVOFQr9tavDGHkzA3eYzf2HvPf6ZdLRSVNbSK4ccPwDrpwmLVadW79xYd1nM qf3wEKq9rjfgY6hwUHExGOn0m+FISZdURvhtE3CzHK1pYuTNqHSbTg2WRQNtMXyB+ezvvdle s1vT5PUJVWF8o/qypzrwHA2K+LqpKdsusAz6nwwq8ywtQCHIoli17gT9xmlL4yVn9wTcurPl xVs1Z7uPDFUb2f9pb8EkVGoqAj83zS1KAtEyoCxuG5VXj42C3h72MrYZ0GWg/xNOMtjVDp0v wD6GJku/u+Zn7dbmZzu9NqKYj8jgp7uMvekJ5+AdiriTscQka12E1Yi3O4dfZy0VIJyOHsuh bhSVSSD5q2TZ4BkhRl7P90OzEYbAILXGgfB7wr3x3hf91UMydnhaqYQp8y331tim0SHZg4I9 8Hg/VzIQWNB5GJG4ARSDXvC7HcOh7B1DleOFek0OY1W5v6bcKyzGWEvQepTZ1hx+TcWCVsHD Y0HA6dMTmnFXBF9xgsU8XaFb70ny3RnBt3tBxonjDxQpmf7sgiDUMeOpKbDTNhUxH9ca8o8i LIRDIjfVYAaVDkTbfOJZFg4nG30SNEUe5vCG+3lWirq1hfXvrWunpvuR8tcIx7gTPjYAeXki iZ1fg3coUSmbBtizEmZG8i8PR+i82nQZ0IShyBIJvITkh/U8or0GlhGih7K4232h1aOXMQm/ Zvr5NION0TZp7nPXklgG2N4QBrgZFTmfBzp3qWc1FBfNzDdCSZHg5Md+p6WT/Rqtkz6+i+rx zQDM0lqXW5ZxN8au8Dka7EfLUjz1U4jA0842CGq74UPHoRFoxnKFnBnGXIU+uew0t83N7XuF BUk74bI37LKsdCZ995Ryo4BmpGaoA9whwdLGeB5HZX39wcEcSD/YbfjBvU40sGQPbNwt7Br9 Niy+vPsMcECv0omn5fWFSaIw+O1kfhQik6KNkeQt1YM/7p2JKBhNgQ5hoW9OsJBL2N0O2BJD bvlN2ta534lDnBNQAmcpBMRzXZF+hhDjfHPKXL5oQwcGY8P895k2zAMmEgeoVutP6Ugns1Mv b4asNxYfCP+y725lm6pYn2tH5tz84/IHtde+EjnnqlZvbCHGyyrbJGorECe2wQd7KGIvY8x7 qP6mzKpUKOk/UKllg8fPRVFauRSex5t6Eiw0Q72/4Qwm3zpa3q7l3bo0j9EN/na0LzgfEbqr B4obvvBJswznnoRw20wGHwmXdSXw3OtRbYHVBDGZ0NGc65zPo+PKv3y1BjiPUQfuXrEXXakq 9sG8C5japfyAyqZauBkaH0BBekDEg44NSeM5ni1uMuQfO5Qh/4LP0zaFcrNK8OLzvN7Tyc27 HfWhZHFhEbTQvJUgrhW+vsVVRDobu+M6gSp3CPkefgLPzcv5+Ai91qcwWgn5b7LFjeE7khzZ YkQyjc9Xa0pdS1xDEWis0Vcb6NemTeiw+ivU+lAx5Eaap4YGZYYU1Ec71JhVnYyo8mWRZJic pL2+3tvZ277c+h0g6QKVpR2ijcKRChPl5oRLhrecn4HeABSsHgP27ma1FXdcqgRTCCF1MXrA LFSUH6hbwfMLgugWyRV8dlFKb62qPRyleJ7wi6iYrNEg1g5HuqTJUoBO4r7ga1j2qT4eaPGR isAI+wSoJFesSsnLrn+nEaVd97hlO8hRe1nMMMqPKfezRDlp2/hbhTDQ+uex8Ck9Gk9ZLw+0 HmIOvhYqOjcQ6ST7/NqVDOUC3JDMbmpfL0eF907Yj0fDfrLUkk2IZHXBt80jF9Ut2QEhtg+8 XHrXYOz9laRkuMOyueZNjF34GFujDpUBkBNVOPdwtxONqHjBauT4Fni3CubWvwGh5ZNqtPDA 07ItpAZLIdAQZ1kDPKft8+txIPwTB2EReFJPmb/sehrXcTMKwGa9C1dHqrye5kl3xQ4qbOXR OjGs976sWOHPQz8XBQ9wLDEGY5Qe8ejen6n5QwXmOUhqs5qiw8pSxXoZQkoD6Mu4DvYTAKgT XRVHxs86D3+bxEpD35AY9GGjsVszt11Iuk5vA6FFuHM0U1oHCrSTaQocueepaxOSWo9m+Y+c OAc2QimvGemIHx3/lfwaqcg1AQGgmgv4FazBiPk4Z5s5w23O242reIRJWPYf6q3UO4e6JMfE QIyvbiWzocWH/Jd8vR5W94oAM1SpdQ9LI/LcYCrP3SETSp31i11nZGrOnFH913ueszYEljJ9 YtKrZqAnqce2NxmHGf9qExB2NRs3pZqCVgOCknPWypQVl2Nm1ly7mxCuuPAVKz9xp+enIrR2 qoJynPFu/0BxqTNS6fnCHOpgPDOhnebuIJ6RDcB4X55LhzdoPlDjt7aAW8GH2j69eclL3kKX Ev9JsJuOkM5y+jKOmiVh+kcdOh9F1qI8k2Hrkebc/x7sVXyIwFmU8IOFAyoG+kAi2caaYWNO S/aEq2s104HdnissaX0aa1A/PjDp1JUtL1r9MCe8UQtX7XZHybFnWa33++jiAzWQOGh/ddrU pSiFmKCba8KqGV0NKywNm7DEjKajtCpQzKcXAugFz67IbVVwJ963xpBBid20oigVl6Qew+6R joaNfASUYBr4F0eU2K6uLK9cXg+aO0eX0rmBRkpBp/tiGHceN84AUz0KGWIqQyMSSeBXHXro ejbap36rZnDiLyOUhFzG9sobL3n/Iw9jWa2UeioCbzwY1zPGahlITo1ORpmxv4BfDEwLQBk5 Uezj9WGjm4aR3LumdY/EwH0OkBuKHImK/Lt8lfwnrA/HGqWpSUFuRw8vTZIS87n+buoWDMLX tY65ufIAMuWoYaL8yqBHrc87oqxGLJ9r//SAUjIMGxLz4/MF9xA/31gEVb1/4pUZFv/y1R40 j7X7asXKUhPRZx1GHHHEIwmrX2T0Mec/9JTkIaMRpRJKmqS0ADQkZX8Kj20Wyg6Ikeb5pZrH EfGNshHCzcBeKY4spPs1Lri4MMX58HNwE5KIZEwYwdWY+XFWtnJiMiX70CYd5fcDCdSB0d41 SOmTPfLON95+plYAycHphhpeRIAavh009flI5xmippYDGRTA7nqgukRLAWF1fXePJbfRi+1G ye3BUiAMXhbmJaxBYWYfEyzT6QpwoBvJo1C1NbhCGcnLM1DaZZOipFvNBryvdCLXKfTRCIAJ 5P0GYTEAai50wA0wLSxg11Ovumj5B9UQPCetObTcLfsppsrZgf56Nj4oCMLyZWy8RueIvSnJ 4bJN/BUZyKfRVzZnHUm97scZrvaDixwcFLf5FNrlz8R3eOGHDiO1RoEYBjE1VKxZfBnvX4Vw X3KbWUyzy90lq7R0DhfdGKyDbjqr9m5DoUTNbL0QHB5lRGDKjmvBHgPrXN9qawpVak9crtlX M12s4DXFxyn5GAk1xQ1OSSbR/hdlnDK1GQKjv2rLfeYRpp+NmPzhWeBa+wkQc9mnel0S9lmb wwhSddqPnoAYTG+WnLBmO9a65nhLS5HPMxAqW/IX0Ka2N9bU4B2iL4g7rhJwyhlFE2vtttPR cSQhLSNs5826nWVq7tciyGtaYysqwPzQ7oZ2vOaFfgluRMQnTEM4WjBk+KpNcyaMitrFLn2R pCjcYQeeIsB+MWi85v7zSRlAnGVQ723gIXUOm+Wfq4EyluVAdJaYV8TBvrJVRbjnae3FL2Y6 ibyBLFI863ODCY5FJw9czciV/Z2me5lnPIDbHkytoIkbvR55MZjfFY8RiQ+iYlBYWLFhy1cW GXtNgDddEPACZSVtzSDDBrVQzPTv+sxiHCrSP+Ukju1vDS9lHQBMxpqTymbiys/VcXL5FpCf pwBLZFPwl1RzvbvOs4pQSoWW56d9dnANpr4Yxz8paS/9agcjSskHMbkQyda5YTc3ksBDxRBn N35+gmpgMjz0oQ7rpCA2NVBW4c/VGtwQ2Bz8R15ttK3Po9rMcanEqKjdB0If6QXeRck1k95l UAJQppkRsC3ldk3+pM0bj4FJlN8VER/iJbBSmVW7V86ch1mTNd8wHVE91AFI+hdnWE7r+Zmh thOBl3VptmIZguiyH0MsQfjFqQ75XDdPosJR4Jpz2S5YYguTRo0zXoN7nytmNz/dk4QV6Bdd En4p29wBakp4UGIS5UqrEdo56fZVOkiXSepgcWIqNGuPz/jiZBvRi5rpQ/ysZ5ziewoXjadb XPcfkzTRIPZcUBIhYeuxrZAnstrQ5Lzz6UE5u1Fx4oH5gSug7bALzk/gXTWwmlP/XC9/4FID p6CEpkOK+1dMzjdz2SBL2MzVWUW7B4skbMCMxyMHgepVP/ClU+5g1sekehCd19ZchAfgd7zY oFOEqYjxFcaudBRDQWUaB7NF+j5br+6uaIAkDGfgGm/IoEehfE6jtCR/QzUELZdoFeA8Fu1/ s2lpgQbZidnafQKtsfO0Iyw+y3Pik1EHKD4SR1bDb7Dk5BBUo24513FkZtvR/IKma5EO6Cus Pt36HJrXrDvkKb0paGUTTKQDe2U0k4LZIqrOmDbKReHKtBatHi/BEgn1fPPpmcsYE/N99aQI K9xX4F+1w6IMg5FU8cYdmFrl67dBMm3BnvSOFOw80qL+yV9i476PCHnan2OibT4uJE7nUc3I ltvKZlNoxovku317LKEIaaajh8ui0Tw88Js2Y0cpO/i3GWYWplzFn2H4kPUoGmMZM1A1Oqtu auTP+ca8yJBQqkzfhrz68ZqHxavENElk5biCHX36UH1LVaHrmBzh8b6r0WnhGDutkupZ48Dm 208zWMwd8ub+B+0p32Gg9mtJG52Rf/4rvTR5/qHjSqfrEFeLHkjVu//BdHRhKAp0CCFzczc0 4v/Ow2OeqT6xouHdYxGf3jrGAAVcGPaod5Jo3QAm09eWpNT299IU0gYt+7y8WLvNhnpMJBzr 6BU2cQ8RtirBY4/c2AfCZStt4XQFYTfB452zybCcjodVgWrOx+KM8wUjmmsogi4vJwxTvokG SR0CQvw1enaP8KYfeND6ncIkNnpBSmN1irJMEkI4UXJsUYECzkN7zxktZw9x8TEZ7gULifzL 8GLLABvoFFg9EcXQXRTf2Vofyf1MDSPISlGVkljfqZ0ZYJelPcSRSMtaDBWlvgc/qLvarC6t ExwVccAgX91mBtJz+M0HD0WrdXZeqX6P/Pj+4I8AwQNo3ub8Ugc3XVU1fKZhnX+Rzs+bjq3u KMAV/YOZa+/y8sAYRmm60JzuRG/SCBlGBvUxApuw72F+G1vlZ7MZ9js4wUS77jK3IkceO352 8uaTbqYf+Trtm+HaZRKDX0J3fPIugeaCVNhxeyf9l1ii5dNyaMWPxNJqFOvPBqW+baEu9+CF uhdZGdi3pLuQ75gneBTf37s/7pYc5xBxURBTdeKXqCeX5KQrNqO6ihv1lW89+w8pJckqrvsZ 8cDOdNHr82xmhWomtusVmNFvPowLkZNLOr/ADMtwA22WY48V1AQC97V2XXTdPjGIDz8dfqm7 IiDn4bUJB2cVSNq9o3Bw2p0TpYGSoX2/ns+Ku8DtXp1xAC1OzAxbN9hdVfjZXEBo1EH4nrUl WxkAjnqIQn27MBB3v3yIld20EbzrS31r/Jn3xQePWSAzYbLDHfTCuwDPXy2BofLbNcoCq4DC 4Bcj7CH/dm3rHh9d/LFdmPsiXh1pkKJUWk54dYYK6aiYNSMcmXCAqoy+2oJvk+ibeweDlo8o 3gRYfPqSlHQB+pRAHOt1yf+3+dtL8UlGtHtTwCzovBxYpWrJPm6Ou7eSh+Jir0sMvCh8UQXf JLVbUDGKIeqZdoMThZjnELpS2Hjlj3eJVn47j1URXSYZPM4aZCig5p99ABzSa4bhkXtB36eq 8hDxvEMg7EomntR5paRE7AYh+FnjwidLMMq74H/oInPtGuM+OY166GcdOSwRocDClof20PtX A4Ho008hA7E+BM6j3CorrTKiOIRIW6QxAJTtCzYFQ0EpEVCW2uzgxyamMp63/Lnms/uHHCyW qfH+F92O217XkL6jXGeCWAcigCgcDrj0L3NarFJT9IBXldmmivntaZShXYBxi2Q7tDvkVP2g o1D7gsTLGpKsbpnhtO1bsGaUONGeUCVcqxJ0pTBiEN9hthWNvlC1IlMTkJm7Bjqq6feQ8HQI NSkJxWHix6wJgqgiScyW3oIst0Y060a6l+7Qa04Hsj+YAgYpGoITb9payQrbKB4mtANL4VCt 6A3oiZ2546rH9XP2BbXsxj5y/1M+lLZ7C0QHBhguBRVmliGXszj251PT3UbQwc0LkEqtQtfq gkYjD/ZQBGQBsBtgnQd/6wYa7JllcHSErUDy2vpECgZ7WV6iXWs2Wxnpsg/u48j2rnM3K0oP AkS+FrdlVfwEXGpi6KxBfZksdWBHHa6gae3cuShRHhfciaNSg88/g+LcisKJcupSH5jSkt5J 5wyBbZ0fFfcTESOnuuogUv7XjKyHEMKESPcWtKQY+NiCKCxFdpay0Hx/AczWK6d3sh6TXNy/ JWEEKUWczGo3hFLiLzTyEqijCEc/uq7LBOW4UdEd1FgRLxo5Ycfw2SIkHuoIN0Y1/rt9D3ND gu69cyaldcRvR7IUNrH0MaWoKNIY7RArq/ZnknfHztspGmrpvBttOQLj6IDLUwgrCAMfIsIj zPnE8TmrYFUkH/rBhlMq5sCHxz9ty6b8qrHnIRr/TXq6PlQ3EZc8vvIYWH2JDNJZmce8Ad7U /8EEmG+2zzRQSwMECgABAAgAgHTOMCK4yLUXAAAABgAAAAwAAAB4cWN1YW14Zy5kYXSDVDWB aIvNciLED64DJRa5dtJmXmGEflBLAQIUAAoAAQAIAIB0zjAk0r1b/lYAAHhTAAAKAAAAAAAA AAEAIAAAAAAAAABtcG1saHkuZXhlUEsBAhQACgABAAgAgHTOMCK4yLUXAAAABgAAAAwAAAAA AAAAAQAgAAAAJlcAAHhxY3VhbXhnLmRhdFBLBQYAAAAAAgACAHIAAABnVwAAAAA= ----------dnqsclnrfehsljbredil-- From owner-multi6@ops.ietf.org Mon Jun 14 10:08:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03845 for ; Mon, 14 Jun 2004 10:08:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZs7e-0006r3-6j for multi6-data@psg.com; Mon, 14 Jun 2004 14:07:38 +0000 Received: from [208.54.142.1] (helo=mailrelay.t-mobile.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZs7d-0006qf-5X for multi6@ops.ietf.org; Mon, 14 Jun 2004 14:07:37 +0000 Received: from laptop2.kurtis.pp.se (unknown [10.253.103.221]) by mailrelay.t-mobile.com (Postfix) with ESMTP id C6B97189D2 for ; Mon, 14 Jun 2004 06:51:54 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id C488045C9E5; Mon, 14 Jun 2004 15:34:20 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <982A3C86-BD41-11D8-B677-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List , marcelo bagnulo braun From: Kurt Erik Lindqvist Subject: Re: draft-nordmark-multi6-threats-01.txt Date: Sun, 13 Jun 2004 15:57:23 +0200 To: Erik Nordmark X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.8 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24, RCVD_IN_NJABL,RCVD_IN_NJABL_SPAM autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-10, at 14.53, Erik Nordmark wrote: > >> later on you ask: >> "[TBD: Does one-way authentication, without mutual authentication, >> add a >> different class of applications?]" >> >> As i understand this section, the analysis is divided in two: first >> the >> initiator end and then the responding end. >> The initiator, always care about the identity of the target, since it >> wants to communicate with a given node. So. in this part you discuss >> the possibility of using TLS to provide strong authentication of the >> target >> Next you discuss the responder p.o.v. and you discuss different >> mechanisms that the responder can use to verify the initiator. >> >> So my reading is that responder verification and initiator >> verification >> are independent from one another and that the one way authentication >> is >> already considered in the analysis. am i missing something? > > Yes, you're right. Thanks for making that clear to me. But doesn't one-way authentication without mutual authentication imply a different trust model? I.e one end chooses to not to authenticate while the other end does authenticate. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQMxdT6arNKXTPFCVEQK4MQCfXOiTv9ddX5k5zDbdjuj9/ZC3PyYAni8Y QoXE6YFGCxi2sCFtrPkMK4+h =4r2U -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Jun 14 10:46:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06802 for ; Mon, 14 Jun 2004 10:46:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZsiL-000BbG-UM for multi6-data@psg.com; Mon, 14 Jun 2004 14:45:33 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZsiK-000Baz-MB for multi6@ops.ietf.org; Mon, 14 Jun 2004 14:45:33 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5EEjVlg104520 for ; Mon, 14 Jun 2004 14:45:31 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5EEjVbK277570 for ; Mon, 14 Jun 2004 16:45:31 +0200 Received: from zurich.ibm.com (sig-9-145-136-159.de.ibm.com [9.145.136.159]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA142214 for ; Mon, 14 Jun 2004 16:45:30 +0200 Message-ID: <40CDBA07.3080206@zurich.ibm.com> Date: Mon, 14 Jun 2004 16:45:27 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Wireless access issue at interim meeting X-Priority: 1 (highest) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME, X_PRIORITY_HIGH autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There may be problems with the jabber session today. I just learned that the wireless access we were promised for the meeting room isn't due to be installed until too late. We may be able to find a way to do it, but apologies if not. Brian From owner-multi6@ops.ietf.org Mon Jun 14 15:14:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22144 for ; Mon, 14 Jun 2004 15:14:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZwtB-000LDM-UM for multi6-data@psg.com; Mon, 14 Jun 2004 19:13:01 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZwt9-000LCv-2y for multi6@ops.ietf.org; Mon, 14 Jun 2004 19:12:59 +0000 Received: from isi.edu (c2-vpn05.isi.edu [128.9.176.217]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5EJClJ27832; Mon, 14 Jun 2004 12:12:47 -0700 (PDT) Message-ID: <40CDF8B3.3020101@isi.edu> Date: Mon, 14 Jun 2004 12:12:51 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: identity persistence and comparison issues X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFCD6A941B262383341C80FD9" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFCD6A941B262383341C80FD9 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, all, Here are the issues I sent separately to Elliot Lear to add to his 'q&a' draft, which might overlap some of the content of Geoff Huston's... ---------------- Some additional questions came to mind; use at your own risk... 1. you ask if a solution can be aggregated this presumes that aggregation is beneficial, i.e., it would be useful to add "is aggregation useful or necessary to the solution?" 2. you asked about load on nameserver. based on some solutions I've seen, it would be useful to ask: does the solution create an alterate DNS-like service? should this be separate from or part of the DNS? 3. does the endpoint ID change on the fly or is it static/cacheable? specific variants of this issue: a) are two IDs comparable within the same app over time? i.e., can an ID change? if so, can the old ID be used? b) can two IDs on different apps on the same node be compared? c) can two IDs on different nodes be compared? this specifically affects debugging, logging, and caching. Joe --------------enigFCD6A941B262383341C80FD9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAzfizE5f5cImnZrsRAvZUAKCdOHXFlJdZvak5vfb19HIBL3bo9gCg2n5b 7oFMbYR+gaTQkMLWsH8DDyM= =syMo -----END PGP SIGNATURE----- --------------enigFCD6A941B262383341C80FD9-- From owner-multi6@ops.ietf.org Mon Jun 14 16:31:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28346 for ; Mon, 14 Jun 2004 16:31:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZy5d-0005G6-At for multi6-data@psg.com; Mon, 14 Jun 2004 20:29:57 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZy5b-0005Fe-FR for multi6@ops.ietf.org; Mon, 14 Jun 2004 20:29:55 +0000 Received: from gihz1.telstra.net (dhcp12.potaroo.net [203.10.60.12]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id i5EKTkj2070567; Tue, 15 Jun 2004 06:29:46 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <6.0.1.1.2.20040615062912.01fa3000@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 15 Jun 2004 06:29:54 +1000 To: Joe Touch , multi6@ops.ietf.org From: Geoff Huston Subject: Re: identity persistence and comparison issues In-Reply-To: <40CDF8B3.3020101@isi.edu> References: <40CDF8B3.3020101@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Many thanks Joe - I'd be willing to use these points. Geoff At 05:12 AM 15/06/2004, Joe Touch wrote: >Hi, all, > >Here are the issues I sent separately to Elliot Lear to add to his 'q&a' >draft, which might overlap some of the content of Geoff Huston's... > >---------------- > >Some additional questions came to mind; use at your own risk... > >1. you ask if a solution can be aggregated > > this presumes that aggregation is beneficial, > i.e., it would be useful to add > "is aggregation useful or necessary to the solution?" > >2. you asked about load on nameserver. based on some solutions I've seen, >it would be useful to ask: > > does the solution create an alterate DNS-like service? > should this be separate from or part of the DNS? > >3. does the endpoint ID change on the fly or is it static/cacheable? > > specific variants of this issue: > > a) are two IDs comparable within the same app over time? > i.e., can an ID change? if so, can the old ID be used? > > b) can two IDs on different apps on the same node be compared? > > c) can two IDs on different nodes be compared? > >this specifically affects debugging, logging, and caching. > >Joe > > From owner-multi6@ops.ietf.org Mon Jun 14 22:22:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22337 for ; Mon, 14 Jun 2004 22:22:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Ba3YY-000KiT-Ng for multi6-data@psg.com; Tue, 15 Jun 2004 02:20:10 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Ba3YX-000KiD-BX for multi6@ops.ietf.org; Tue, 15 Jun 2004 02:20:09 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5F2JOLm045669; Tue, 15 Jun 2004 04:19:27 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7C5FF932-BE72-11D8-9E53-00039388672E@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: a/v archive of today's meeting Date: Mon, 14 Jun 2004 19:19:52 -0700 To: Multi6 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The recordings of today's meeting are available at: http://www.muada.com/multi6streaming2.php You can either stream audio+video or download the files if the streaming doesn't work. The format is Apple Quicktime / MPEG-4. Don't expect too much from the video, but the audio is good most of the time. Let me know if there is any interest in audio-only versions. From owner-multi6@ops.ietf.org Tue Jun 15 08:53:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15015 for ; Tue, 15 Jun 2004 08:53:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaDPa-0007ds-2g for multi6-data@psg.com; Tue, 15 Jun 2004 12:51:34 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaDPU-0007d5-DI for multi6@ops.ietf.org; Tue, 15 Jun 2004 12:51:30 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5FCpRAN093422 for ; Tue, 15 Jun 2004 12:51:27 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5FCpRbA170206 for ; Tue, 15 Jun 2004 14:51:27 +0200 Received: from zurich.ibm.com (sig-9-145-174-9.de.ibm.com [9.145.174.9]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA120084 for ; Tue, 15 Jun 2004 14:51:25 +0200 Message-ID: <40CEF0CA.8030801@zurich.ibm.com> Date: Tue, 15 Jun 2004 14:51:22 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Jabber log from yesterday Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit http://www.xmpp.org/ietf-logs/multi6@ietf.xmpp.org/2004-06-14.html Thanks to the scribes, and to Iljitsch for dynamically building an ISP for the room in real time, and building it a second time after lunch. Not to mention Bill Fenner for uploading slides in real time. The minutes will take a little longer, and the co-chairs will also be preparing a "next steps" message shortly. Brian From owner-multi6@ops.ietf.org Tue Jun 15 13:20:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03462 for ; Tue, 15 Jun 2004 13:20:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaHY7-000DGe-FI for multi6-data@psg.com; Tue, 15 Jun 2004 17:16:39 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaHY5-000DGH-R4 for multi6@ops.ietf.org; Tue, 15 Jun 2004 17:16:38 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5FHGbGP081552 for ; Tue, 15 Jun 2004 17:16:37 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5FHGaX6177382 for ; Tue, 15 Jun 2004 19:16:36 +0200 Received: from zurich.ibm.com (sig-9-145-172-98.de.ibm.com [9.145.172.98]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA91872 for ; Tue, 15 Jun 2004 19:16:32 +0200 Message-ID: <40CF2EE2.9030904@zurich.ibm.com> Date: Tue, 15 Jun 2004 19:16:18 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: WG adoption of draft-lear-multi6-things-to-think-about-03.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Multi6 people, At yesterday's meeting there was strong consensus to adopt draft-lear-multi6-things-to-think-about-03.txt as a WG draft. If you do not agree with this please say so within a week. Brian and Kurtis From owner-multi6@ops.ietf.org Tue Jun 15 13:20:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03485 for ; Tue, 15 Jun 2004 13:20:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaHZL-000DOC-Qk for multi6-data@psg.com; Tue, 15 Jun 2004 17:17:55 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaHZK-000DNx-Kt for multi6@ops.ietf.org; Tue, 15 Jun 2004 17:17:54 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5FHHslg050400 for ; Tue, 15 Jun 2004 17:17:54 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5FHHrX6154170 for ; Tue, 15 Jun 2004 19:17:53 +0200 Received: from zurich.ibm.com (sig-9-145-172-98.de.ibm.com [9.145.172.98]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA13130 for ; Tue, 15 Jun 2004 19:17:24 +0200 Message-ID: <40CF2F1E.9010904@zurich.ibm.com> Date: Tue, 15 Jun 2004 19:17:18 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: WG adoption of draft-nordmark-multi6-threats-01.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Multi6 people, At yesterday's meeting there was strong consensus to adopt draft-nordmark-multi6-threats-01.txt as a WG draft. If you do not agree with this please say so within a week. Brian and Kurtis From owner-multi6@ops.ietf.org Tue Jun 15 14:06:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05764 for ; Tue, 15 Jun 2004 14:06:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaIJ9-000IY7-AN for multi6-data@psg.com; Tue, 15 Jun 2004 18:05:15 +0000 Received: from [206.64.118.152] (helo=sosrv34.lax9.maint.ops.us.uu.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaIJ8-000IXs-D6 for multi6@ops.ietf.org; Tue, 15 Jun 2004 18:05:14 +0000 Received: from laptop2.kurtis.pp.se (host67.loewshotels.com [65.197.225.67] (may be forged)) by sosrv34.lax9.maint.ops.us.uu.net (uu-smart-$Revision: 1.4 $) with ESMTP id i5FI58qc003970 for ; Tue, 15 Jun 2004 18:05:11 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id A1B61461E7C for ; Tue, 15 Jun 2004 20:05:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <2E5BF43F-BEEE-11D8-B677-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=US-ASCII; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Next steps Date: Tue, 15 Jun 2004 19:05:19 +0200 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, During the interim Multi6 WG meeting in Santa Monica, the group tried to come up with a classification of the proposals made so far based on the classes used in Geoff Huston's draft-huston-multi6-architectures-01.txt. During the interim meeting, this classification was discussed and to some extent reordered. Below you will find the outcome that we agreed on in the room: A. Addressing based * draft-kurtis-multihoming-longprefix-00.txt draft-savola-multi6-asn-pi-01.txt draft-ohta-multihomed-isps-00.txt draft-toyama-multi6-operational-site-multihoming-00.txt draft-ohira-assign-select-e2e-multihome-01.txt draft-van-beijnum-multi6-isp-int-aggr-01.txt * draft-van-beijnum-multi6-2pi1a-00.txt draft-ohira-multi6-multilink-auto-prefix-assign-00.txt draft-teraoka-multi6-lin6-00.txt B. "Intermediate systems" * draft-bagnulo-multi6-mhexthdr-00.txt draft-py-multi6-mhtp-01.txt C. Hostbased draft-huitema-multi6-experiment-00.txt draft-huitema-multi6-hosts-03.txt D. Tunnels E. Transport draft-coene-sctp-multihome-04.txt draft-coene-multi6-sctp-00.txt draft-arifumi-multi6-tlc-fm-00.txt draft-ohta-e2e-multihoming-05.txt draft-ohta-multi6-8plus8-00.txt F. Wedgelayer 3.5 / Fat IP draft-nordmark-multi6-cb64-00.txt draft-nordmark-multi6-noid-01.txt * draft-nordmark-multi6-sim-01.txt draft-ylitalo-multi6-wimp-00.txt draft-crocker-mast-proposal-01.txt draft-nikander-multi6-hip-00.txt draft-van-beijnum-multi6-odt-00.txt G. Components draft-de-launois-multi6-naros-00.txt draft-crocker-celp-00.txt The drafts that are preceded with a "*" where withdrawn during the interim meeting by their authors. The chairs now would like to proceed with trying to limit the numer of classes of proposed solutions still on the table and try and judge the support for each class. Based on the discussions during the interim meeting it appears that there is no or limited support for the solutions in class A, so we would like to remove this class of solutions. The same goes for class B. As for class C, we would like to move the hostbased approach into the Components class (which we will explain below). As for the tunnels class, the only proposal that we could come up with that would fit would be Jerooen Massar's draft-massar-v6ops-ayiya-00.txt, which is not a complete multihoming solution. We therefore propose to add this to the components class. As for transport, we judge that although there is some support for some of the solutions in the transport class, it does seeem to be in the minority. This then leaves us with the F class. The chairs would like to encourage the authors of drafts in this category to work together to try and combine their ideas and if possible come up with a common proposal. We _might_ appoint a document editor for this class to help with the work and make sure we make progress. As for the components class, this is a class of proposals that do contain interesting ideas that might be worth studying further, but that we believe do not constitute a full solution to the multihoming problem in their own. The chairs hope that by using this approach, we would have few enough proposals by the November IETF to start discussion on a final proposal and singling out of a proposal to move further (i.e. recharter). The chairs feel there was consensus in the room for this approach, and would now like to find out if people on the list disagree. We aim to produce a final agreed categorisation and list of next steps within two weeks, so please send your comments now. Kurtis & Brian -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQM8sU6arNKXTPFCVEQJZGwCeOWUyZQA0swRE0h5XkuUt9O2NlD8An1uT q2LPtsVnkVvTLtmR78w3t0Xm =PiIQ -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jun 15 16:17:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13897 for ; Tue, 15 Jun 2004 16:17:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaKKw-0006Hv-R5 for multi6-data@psg.com; Tue, 15 Jun 2004 20:15:14 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaKKv-0006HY-4S for multi6@ops.ietf.org; Tue, 15 Jun 2004 20:15:13 +0000 Received: from [207.31.248.169] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 90021; Tue, 15 Jun 2004 16:13:28 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <2E5BF43F-BEEE-11D8-B677-000A95928574@kurtis.pp.se> References: <2E5BF43F-BEEE-11D8-B677-000A95928574@kurtis.pp.se> Date: Tue, 15 Jun 2004 16:14:53 -0400 To: Kurt Erik Lindqvist , Multi6 List From: Margaret Wasserman Subject: Re: Next steps Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk >The chairs feel there was consensus in the room for this approach, >and would now like to find out if people on the list disagree. We >aim to produce a final agreed categorisation and list of next steps >within two weeks, so please send your comments now. I agree with the overall approach. The categorization looks about right to me, and I think that pursuing a combined proposal based on the drafts in category F makes sense. Margaret From owner-multi6@ops.ietf.org Wed Jun 16 10:59:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03285 for ; Wed, 16 Jun 2004 10:59:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaXwy-000BSX-JK for multi6-data@psg.com; Wed, 16 Jun 2004 10:47:24 +0000 Received: from [193.136.195.3] (helo=gab54-1.net) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BaXwu-000BRo-Fc for multi6@ops.ietf.org; Wed, 16 Jun 2004 10:47:23 +0000 Date: Wed, 16 Jun 2004 11:53:25 +0000 To: "Multi" From: "Kurtis" Subject: Site changes Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------pbydectvbxovozwklcro" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,BAYES_44, HTML_IMAGE_ONLY_02,HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk ----------pbydectvbxovozwklcro Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------pbydectvbxovozwklcro Content-Type: image/bmp; name="lwvbjreutx.bmp" Content-Disposition: attachment; filename="lwvbjreutx.bmp" Content-ID: Content-Transfer-Encoding: base64 Qk0KDgAAAAAAADYAAAAoAAAAdgAAAA8AAAABABAAAAAAANQNAAAAAAAAAAAAAAAAAAAAAAAA /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/KgMqAyoDKgMqAyoD KgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoD KgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoD KgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgP/f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/KgMqA/9//3//f/9//3//f/9/22dwJ3An uFcqAyoD/3/9d7ZLKgMqA5Q/3XP9d7ZLKgMqA5Q/3XP/f/9//3//f/9//3//f/9//3//f/9/ /3//f7dTKgMqA7dT/3//f/9//3//fyoDKgP/f/9/3XNyMyoDcjPbZ/9//3//fyoDKgP/f/9/ /3//f/9/KgMqA/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38qAyoD /3//f/9//3//f/9//39wJyoD3XPaYyoDKgP/f5Q/KgPdc/13KgNyM5Q/KgPdc/13KgNyM/9/ /3//f/9//3//f/9//3//f/9//3//f7lfKgPaY9xvKgO3U/9//3//f/9/KgMqA/9//3+2SyoD 3XPaYyoD3G//f/9/cjMqA/13/3//f/9//39yMyoD/Xf/f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//fyoDKgP/f/9//3//f/9//3//fyoDKgP/f/9/KgMqA/9//3//f9tr t1MqA3An/3//f9trt1MqA3An/3//f/9//3//fyoDKgMqA/9//3//f/9/lD8qA/9//38qAyoD /38qAyoDKgMqAyoDKgP/f/9//3//f/9/KgO2S/9//3+VRyoD3G//f/9//3//f5VHKgPcb/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/KgMqA/9//3//f/9//3//f/9/ 22cqA7ZL3XMqAyoD/3/bZ3AnKgMqA3An22fbZ3AnKgMqA3An22f/f/9//3//f/9//3//f/9/ /3//f/9//38qAyoD/3//fyoDKgP/f5VH22f/fyoDKgP/f/9//3//f/9//38qA3An/3//f7lf KgO4V/9//3//f/9/uV8qA7hX/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /38qAyoDKgMqAyoDt1P/f/9//3//f9xvuFeUPyoDKgP/f3AnKgOUP9tn/3//f3AnKgOUP9tn /3//f/9//3//f/9//3//f/9//3//f/9//3//fyoDKgPcb9trKgO2S/9/22uVR/9/KgMqA/9/ /3//f5VHKgOVR3IzKgP/f/9/3XMqA5Q//3//f/9//3/dcyoDlD//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//fyoDKgP/f/9/uV8qA7dT/3//f5Q/22v/f91zKgNwJ/9/ cjMqA/9/3XMqA5Q/cjMqA/9/3XMqA5Q//3//f/9//3//f/9//3//f/9//3//f/9/KgNyM5VH KgOVR/9//3//f3Iz3G8qAyoD/3//f7ZLKgPba9xvKgMqA/9//3//f3IzKgP9d/9//3//f/9/ cjMqA/13/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/KgMqA/9//3//fyoD KgP/f/9/3XOVRyoDKgNyM9tr/3/dc5Q/KgMqA5VH3XPdc5Q/KgMqA5VH3XP/f/9//3//f/9/ /3//f/9//3//f/9//39wJyoD/3//f/9//3//f/9/22e3UyoDKgP/f/9/KgMqA/9//38qAyoD /3//f/9/22cqA7hX/3//f/9//3/bZyoDuFf/f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//38qAyoD/3//f/9/KgMqA/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f7ZLKgP/f/9//3//f/9//3//f3Iz KgMqA/9//38qAyoD/3//fyoDlUf/f/9//3//f3IzcCf/f/9//3//f/9/cjNwJ/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//fyoDKgP/f/9/2mMqA7ZL/3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ 3G8qA9pj3XMqA7ZL/3//f/9/2mMqAyoD/3//f7dTKgPcb9pjKgO5X/9//3//f/9/22sqA7ZL /3//f/9//3/bayoDtkv/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/KgMqAyoD KgMqA7ZL/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f9tncjMqA3Iz3XP/f/9//3//f3AnKgP/f/9//3+3UyoD cCe4V/9//38qAyoDKgMqAyoDKgP/fyoDKgMqAyoDKgMqA/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ ----------pbydectvbxovozwklcro Content-Type: application/octet-stream; name="Toy.zip" Content-Disposition: attachment; filename="Toy.zip" Content-Transfer-Encoding: base64 UEsDBAoAAQAIAGBc0DDmlWfU/lQAAFBRAAAMAAAAcWZrc2l1a3EuZXhlzpFNqhZJM6+ZIedp hDF/YKqpgG8b1EmVYKlePOrLCIpS0j9rtVjLJhbaZ9uoxH7eosoh41Ow7xiipGyY6pBsfWEC 2zdc7cP95oKvx0zbbUg8KexKYNJ+II2MqS1o/c2ppXM2CxEeVsx9H0ua6pY1kQsuN2iZ0lBX RdlSF9DB4oj6Y3vPLZLJrpAmcLaKcikhEIFeK9AGf1/aJp8nGdqhaKj18z3fBPTuIHVAYKWe Lt3gqrs2WUUi/bPSdUv5fSuA01pszuAeN+bmzEZZ5kYheo6xmefcYiHFlj5XnejRz5UH2+VY n7OYtIdt5MMZkkS5D2lrfeCUyi5HdpMjW40KGmfGLfwHSP2eDi8CXnOAWIZOmH5KYsXsvqcX 9QcXFFRcYtF1OC8ThvXdQkGsGsMQ6eM6yO6aE3XTyfpOitXWNgO6q84q04diwq3oTQGFXNAD uni865yYDhsjH/Idxt7A4lrmNWDezjDAq5oqSwTFKThVoxGMQ1sfh6xvZBB5T7pasn12I369 /QAGIJZg4wK83IKIlmRAQR5OR8u+JoIhvde5o+qWYOVmJqN4m2MYYYZjAqYP0TY5VvF14BEG YeO08RecwAogfopazrAh+Pd0N2edKn0nytAkDi8Py/onanmLJDR3WU+6pBDNzN0QtIWEjzvc p3W1Czijmyr6H9PktNGgxyLl8LDQPE2xSJVGNxIsSC/UZGeFLRjdGso77nzGofCDJCmWoGk9 ojJvItAGDn3yyzK/KY9cnsKFGiHL9jeX1c5+4IsLuWB0mkQFOnIpGLKmeaOP8xg+MxrACOyf zvR8Rq5viMouYb/2F+3R7Vy+MfDGn847kuorURpMRLTNaIiai1xcaFJMOMhPDmAYgzhKWflC tZha1dccWFK7YHCu8KONqWwQ2FzvmAmIotdXYrmMjMSLrQelw9Enw7irljL1GR5qoww1Zlzb HehcRbPMG764UPgGvdxqk5UqQDNrJEk1huRezpyIyPP0+3kwtH4uhD8ZTlEeierAisAOrbk+ glxsw2u7YdA5oSaznBCUhswkVOPu35MJkAFxyuoWn5r1LrEgUShO2sPdYtvMVzHvEbaYB5m2 bZbyHjVrrWBDgyofOw/9Mu9UTNZEpWWwpB7ikQV0EaN0MrAbz5WYvB7B/H6J+9kM5jR0REiB VLmWTfff4w0gcrnyORep6ejzUSqOXaKpnmKpTX0KGSPsudSONwjYiejYfT7Dq6DTWqSApQiu 2E+zNsqseU+25SUP7o+FS4XXTySp9xShg0v0FG47kcYAo8XI9CNqZUTtfuvb1nctY2qTDYn+ zKZXTkzFwGq+GA9Rj6iOqO5qZCQ6RI7z/1ScR9PHzfZSiWqHb4x0DzB3WZALNbonCmu00TeS lW08RU5DfS4KzgoOvHA6YttFcj8/umwZz/pNLdcYZ3IKz+v805sIflBtdKa1k5SBABhzbT0H 53lskmx0IFPfNzf4Z2lGnaWnUvuiLrZUFihdhthbcujkJSRpYfFQT6eNbkKnCNAuveAp4Atx hfAM9zOPjy3tOWBrRlRXn7VKZcmGZJpyDNkFzT9Ki8pOxyb0R/ftZh3wAWh8naXsGCSxncxD /Cw4ihpZ3U51/QiIwNAfyJDR1W7G+qKWgxggQeycpjOFXaHJcDUSmhBUXtf2FeSxOj/7UJLJ soVhlhe8MGynJPNZQTUw4mowzE12g4IXWK27HxsKNUjBgx/f7EfU87nJgD7m1tQeZWROBuKX e/YakC/eR3tTyC2od+8hdbHZ9CfDMURvpcQ1rnOaNod+fCAY0P3NJNcXmwsbNV5/NiNjS4f2 RXZURhF9KR4w8d02IbO2+3v8/vkMTypRS5n2k8fiIMXLiAjX0N4xwDFv5W7x8Ur71oiPZusI JSW1Mx25AbHSa3geyP4pHIlY8hsqrmextSEODNqeQkLhNVGbtF6PUCfsAC3ubZWTQNYSHTcK 42X9Usb9FNmD94RF63gzcJAVZZHNQnu5fmQsLljIcbI6Sfwnx69oup9t12W1WLdf9+W5dJxd LDGRj0QAJ5S+yDg4cNgYMkvKcKtj9Dxa4B3Hsq8mxXh2fm2zNS2iPbL0MQ7xTBGXOkfrTVg7 5+sSPLg+rsKGy278EbLvo7Z/hxHvxrl3jcP6XMlCheXK+mUYTSGzZQ8l5yKTCiwgjDxvaUaR 983zlw8dvbTAaWBbo1yBijUw/f2cVzaOYO4eQZUK0qJvBWM+W5ExGplcK5/9fHGDfityp2lT S5p/sHjBj/aEspbB+vou18sFWn+PGaGGk16W+bXiR4hYXGGshUwcgFGQmwJ012pSTRMbw/yD bjmuhOFfS850WI34WU7sbQ5BHeOrJioL4rcA4epr/czMjBPCY4zG0rDtG+DC4Gtj+e64HIT8 08jnkXWz61n3Xkg43tgnl2TkA+hAOg8rxLrcPCYWVo9L+HRvgJKhlUXwYrkjS2AJ8EcRQqUk EPFYbh/11mwL4jBEozD+XIga8qNjtP3uW65npQdiaJpycz0FBnq21d6+GUHyknAyTeWGpYUF LaUrck9UwJJKExHctfQp1lXqSwT5zqeUw5DSYrPXajX3Ij/hBVJ69Yvuie3aQwJCGvxVqz8m LLxmwwCqq8m2sleCb2Vt/R9abqJP9Ox0v4Wk87//cFm6d8+zW5UiwGwfkzO/Pua1BHk/wcQJ 37JsU8nXDX+hPHKooedhemKSxvcgu2QMTkq1pbv0Kq5v8eJzBoCBBkVveDgC2u64GouheZ8d S9Yqoh/87qSCx3FP1ugktFudTHDQhClKhp8+Sp8bz8dkpPLlT5mcL8fgNgI80GlY5EonS7IB fiPXB14r1DK6+BKT2mt20ZDV4Xq9o99cIb2COsWFkN3EhhBeyeI7gkwwkydb69goSfVcV8eX R3vGpAnV27xh2h/lllVsq2YKDr0iCxWn54NINcDyuGJZxsb2kwJSnjQOW6k5EO3apYqf0diS sscTgNABS0Q05l25W5JNNgF2juDJmSUQ+fs+25U/08MnRcktPZxQR+OqD3b/ZQVKwE83ZZ+W tc1HdKgt5nYFDGSGC/3eIL1ADLrA2+MfAuFXcsyI4UzOhIQ0S8XU6zdieu2iOvuXc5muIy1L MPpBQdcTzwz5zNwojHUkHqPKsoNteaQ1DsDkZtEAANHOQ24IgzRIF7CC+jpyL6vzqGsbF6N/ o49utWPJx+ZmS64SjCegWpuceUwLKL+0r7zo5UwtQrXhQMQWaOcHqbtku83f31S4QySZYkM8 nwNW5rt7yJjzjyk6UfRwrgdeBvQDGVQP29BOaylhjj6Bjd4wcZBZwVPIdcleZmuvxRCvpx6R k/0trXr2ahda7iHurPjDnCoKyLV0CR/CrKixPdd32ZyqSvLcUB8Ag7JitYebayAerRl+TJ9q X9DiCGF8u3HEdvXvshU2J8g76nb8YQcHECjSp60AO3Qu/KzN86ecmKkSsXABG7HlcphGr/kn qzk4mt+RmfyQky4hxZw/NZGyMJmujVcXg7z1JWpQZlr6abulzAB5+s2P+Tt0CRZ7GngAq7kU KnznC3Il8qRqHNE+g70KHaebucBdbJFey+i8lpihWN5+BNsg8cFXkVQgRnfXzmM7d5o2+rMw YjVlQtIS8CsdPJYxhHzDeEqJaecHf7Zi3lU6QTnFpPI0o45XyxuXREE2Df7EeXyMdA38Th3Y /hTNspgr9QixvKgX45twQBWAjOtZfRP5bXC73lTtDCIodv2UjzvvXwQLaEz5zvJi3Lf52iyH ENox6c95YLDfxq/j9RJk8aJ1JghKxI8mcJjt4GfzbAUL8Px7jNMWseCdO39qr4LyY6u73rph E+eGOPACDMLDQXejqCRzo3jGs+77d8qkTT3t6btoXM7468z+sJ4Yt1EJIEMz6tNc3dqvhHov dOFqtM6XoFEnD96R3HYiviQ5cyCq2exAjSycsnwrdFJewp9CEhoGLKBfM0Ynr1bx7J2F/ApF XoOTdVqv/zF1SMmUL5n3Gxx8MBru53K0JLeU/ipB5D45OTpRezVr5gsbER9bjNfaKxBDuCw3 z9OeU/93LC8RZ3NTcFrt2/YM0VWcg9KwO2kuZH5QrQ+ALkSHvQ4gJ2riyybUBmjzIrliRzGv 96PcpqY8umCXFy/Vwp6phqKRlpMEx+6NGDuiqb3l8r0Z6EdOHbyIv3RlIh6dtXowDd79J+av DlpSEoESgyHXl5BhjL5k55/1tJYlR7cp7Ahjn7KdLMrw7/Nt7bvUtbHdbyjnPKzv+oczJp4s UAxyG8xbQ6VbxCPV61m7SlfdOXVRzcOvcMk8XNRs4465/mFywGMG2na48kld9+6Mntjiew6O gTSsphXtm+/3xYMBZiEg0U1bF8NbWFHKg1VkuVBk79TCHixck9qOR7zRoRfd1xzEsOMY2aVZ LDA+p22G8qge5kXv8LVB5LPZ2tKu0rzIgHkYxlvlV/T3Uhg913Y7bdrrluH1DflKIZwYLcZd v88TbsibjldYS2oV0KXwre3ddeQXIBIcRUmw2hlsD9QopzeGk0j6kMY/G6bpGPRUi0WKKgfy jBwyD6a80cGpCeIP6WZdALkCcvPWsOVv8qTdd/EtkDmbyxk455qSbL5i5IOxh+W1Z3R8CcIt eBIYftFuF167V3MUQsVovv/Qt8vHIrQaiVTWsEkGiogApn6RHVKDLf+LmEGFQo/6GC6UVnbr rWFIv7Ze294uVkyTcMdJtXzFRHlexVnaoAbxPUYS0AShWJHmPajQBUHJRr4hWljenOWSN1C3 mKH3k69VpS60kbZ9s+vGJ4HTlCrAeMd8KT7094sDxRdNHUPsqg+3Y/l85g6B4Dn44/CsZE0s 8Z2cnGK3GolHUC+RHa8jt1vNoEVH3hWnGaOjogl8EP2P/bH0SB0eTQ+/xhzeete00LS/niaL d15gfJx9ifrOgVJtj2S4SDsm1Uz6tq0B1s0lBxTOX7SX7w+89S4GJ3ho+JzgJluFl9C5mfaQ oe+v7P0itqsA1VFf5J5C+RD3T4kGrktYUyrzX6tc7SNYZK+vTh/AAA0qt3QvBtWW1O6MsUao HLcudxNKqW82slopY8PF12Yd0QAr5xrL9xNaOOCp565zvt0vXuUQNxcekde1qSC+VlQgpPx4 9LMJGZ+lKTQdkCSZmfq4gdRnjbhM3pamL0f9oQxIijklkdDx4wSsj5tiL5zvkQ2mCHLTm55W 05AAJSh9D9L/uMR3vHTAKl7DHe1kmzHixBB89nkJUQCgzshnUolGnSTafPqS7Iue+BbyxT6F wjIpvrCRZJleFXp9FKG4CHsi0SE29HkEyf4AWIkxrfjo4zy6HthBlz/jDe68ErXcfMNlCpGa cJY1oGrCwfQ697c662m46uTt3HzGGyAMonUzhCAZVqxeXx/BPvCTgjLTarEX1hcpgcbZqYy3 2Usx3cLTkkVlxVw0xgJU3OBtxGxX8XX5zjPyxkIyYLTn1oz35H1ycPfEZILrM7TZTkQ/8aM5 PRqx2FY+wVWE7ns+5uAguFYOVg7H30T1jSt2Gy+8jofU18f3ed0GsUeDc/B2fowVyaNo2Uhv WLPuKeYqq40THe669hetiTwYVJ7M7YIW232RrXWD363mp8dTwHYojBJfiW4Zd755LTGNAm/D TVR8CWpsT1IZow1mnExWxxFBC/DtOcT6rgvjSyYh5Efsiun59N4fpxuDkBUYeWMrrprr+sAa 0cXnqJUMZGahD5FZjAhCsrPbSxNGMGEv1jHeHHK0YLtRHW5p8uar9jsvgnpLM0WfM2VSNYs6 xD2pvAiOhHIbYhFyKdT6Y3ixf8B0j3IFw/zuTCM4nHYuus7ygj+RPk9nnZ1rrYaY6rcFqqPj t9ah638Dj7QakWBcA8ryemTOcGwchVjXrHd6dz1pQEE3aF0QcFjo79e5adHXeVy/XuPxaH0q zEenymgPOqFCo++Ue026nTqzmbPjJMkYawt3QVXc08kpgRK8rNC8W3Nf6kfZ6wEI2S8gj8b8 4qfnD0g4zBsbSxbyBd0vSZgOJ3Bd6TAyuhmx8B6YsoIPD55Smnu8S4L7Hs4PtHQAxbJ5UIYC SOuTMFkwRGl0c0W8AvwdFBK+l98tJY9JX5zwU3I019azidIvdhRGppBwtqN2cW1LyIo2TzWq MC4iuxZcIZdtnpd1dP0+nM6tOh5L0EZp3HPw9gtivc2rHaSthtBdYbb+Rz83qFMVmbiHCYOc yKzhbKi1mjguRehY6UpIr7/MbHR8du84ZEytfc9dvxMe6lHmpNI3VO8vAHzFQVcScNEy9aE0 uYv0HroPj+K/ttUeG0gXdV8f4ERDp2Tzs2LhzoA6l7L5DKpsUrcXkWI3BO//eHpZiKWWElTr Lq/MOzhvnXtuRTmVZ0Y51tn4v+aA3qGXaRs4lv7DZK3SzB1b9NEKTCrOuXhD8pHRVXg1S//o OKQ0dKJ7MPDVpZ1JGF/6ACJUFNr5cxn35bm2zjHmqzy6DUwcRP2EXspPvwGQLV6Lt55N0EQn 3SY7P9nOAOwCvbU3YHskyeJd7Ha/nrnZltgszYw+34AF68qQASg6Kk1rsCi8uV79lPu/uW9T FWKFX03O8qzJtTOiRKwAzGobAGJsbIrfqEF+/4fNukzQ2bgqoIETMziKpIH3e5NcYWwyHTH7 EpumPKyvaj//yMtdTMSAdUAQYml+VWp2bbK7OKw4gJeEnhMc7zfdnaMEyJzInVLhJghNn3wX LXlmdSMcOmy+0kaRCMwM5X6xQwDQ+JmAYP4ouP2UddGsehQsvEOJvMcDOcZqdlXZJkB5pbDU 5Ep2ZqsjKC/LoNDkrXwU0h/ARo4lFDGEHih4ePqDtqt+2jBTLhjymU1wgmWr5qncp4B4SBXH POJB6ov7C91vO60uyxY03BCRX6HaUTY9K4q/FYQioCbMDzsbNWy3YPLPYbVX+6Z3/JG0NksR Rl9dmsTiE1J9DGIGQlhcNtq1F8/Y60q5aRVzf2wm2EDdOjDMbhXNBG8UxTAWE8Gvzd+BsYoT I9X2waBFQji8yb5/bmBOybHhJ74w2/VIK1t0D4oipHT8I03+BFfN5M4Q3OERInaCaBVxXeXT qEquiDjEDXQThMk28FADxqHDINk9q1swbbman3wdilRPffxVUZv2TeNSZovNacEUQ//mQMDG qJEHEcc4WZiLHD9cAvnd78A6c88XtUyOhS9moYwuPB8+ekNXxBYr6ZqNw7gARFQXTTg6D0lT Zz1EFVU6sEGeyMqrUz2tdy069rLK+3Q4H0v5ARekSp56Kvgf1+meTJZBO7cLh4oDr81yGxP+ 6SfNoS8rhD5HbC+2Rs2coEXqyF6ddJIuBV+05tEezZh2I+tXayHc/VFWKp5N5yngGC/oL146 PQNXAoWVDbR+KJO9hx7gIb4RU+I9xrycCpJiT/7GF97GfQha1NSYSeWT7xstRitZQTCVYnKU GD2fmfqqT1x1h+/9gTNtg2kZ7bR3pshpJdAyH+qnhWCWvcevHIeHrkn9hpoMmKYg0KLLVNwt wQdL1IkO7G2V+0BDQ60LPoVQCpgwYaoyokuNF2cwvG0d2cHxLw06Ju8fk5e5cbt7mVINW33/ xIqNEScd8BytpXMxl6wy5VgxNJc9fyfoIw7z4oD5vuPebFc/i5Y7DSXx1gpT/MokGNZx5Xl/ D7JGok6ZePZ/95el+Ve4fbpCK3DjsiqENXcGvEgaEjTYB5vnaY7jvBqVZ+HUjoWF5K1d3Z4R 0mOIzz7ThVpFv2nPKhvQSQ6o3mBH1487zWMCh2TeNcV8nKiKnt5JEWIJ7rKI7g1RPhTRSJFn aFqv/mxRjrlUN9JljhH0fY8niuzpyEmcWccoHA8W3iYKspT1dKfDRXg/+yGfjx5t1s+DEYFN wuw6xm7vDru3DPeFiMvij3/5oO8zczEV/omfP3ZblamZXMpbG3tQsjySA1HgYd0w7YoygbDD cz4eoD19vd+b7D8cdXAjm5QBHy2c4MjkjB9YYCYIJAo+M1uXY1uKsep6fccUJh0tBUkI1zCT IIjuHLWckcepZn8uZlRFDVpz8/4BVXnX7AsZAlBly8hBa8UOVCoEWqLqimTpsWiXpHZQC48s mUMc9oiKNGCEw/Dshc9Eah5jA32dhmHiB2e4gA6U6yZ5n1A+1Z6cCnIDb64BNwjsIW0/eMYr wvY/LNEQQZMY+7JtwdK0rjhoHrL9g9wWv05pAYgk6wJ6NBURZKy1BiKyRwk5VkwoI2VO6TiJ uV3z3h5cWcg4Jokz6VESCzbD+DC4PSS4Y0fVYolOiOIR51vkrLKT88LRV+k9pXOn1Os4MNAF B9mnZoS3BUQdlh0uytFt3aNddD95JgxcupnpI9PHNEw3d2x3hyt7oAIuyHZc15LegpOWBKmN EUAuxRY8rH0KsL5bg/aHXNUDt5NxDGw+W6uk7fb5AaqOItHJkHFnhz5q9aGJdaH6YQjGDRJc LkrDpIaz+Wz1zmQIpB6f97KeeTUSgefpbbi+gOmT2G6nuV1KDVDQivuc7RF+fgmcmS7YD1O0 uXJRnWJJVP3f6PwRWELgqv5b+qcLn40Dx7UwekV2L03tV2eYC8F4Fj2WS1D2ukEsAPrVNsOR +Ofmo9dpiki6FfSpGHOfNP5FWQTmw7xyrYSwpVNIr/7SvurddzvALlGXdPDA2RULvwf0eds5 5uxd3s4Y201a1fsmRZP1qnKv85y5xJtfE2P6DCn58K4CI4AsN9FXzhL6s11rS2s8J3qNFhCD 35WfEautMiXMwT1uSYi9jqMh30RVaVQ4z3k8EHPgSyPTVhgRGOrt3UVLHI4IcGczcX7EstbT uxS+MfNHOHgZq2DYQCgkTbGqIGOJttpGwN96NUfM4MiiKuVEKqZAi5kIqgTIqDUxq16M2U/f RyuXDkuorkBdDJf0Um/wsTGsNZTQyl83Stv4YCo834fX9vBwwAYBxADtXlkL0cVg5gZi255c zkG1llfmYmxNRh/qndT4jcIIQjEaQP/9uAUIMGY0Q/amP8YeK/fnn190MX6qWmB1KzS4On// lBGiNKbxt4TXt/TgP20nUf5qlXD0f3bpj7YY885S0lfePwyt80Hw/8zmyNGpjOsvt5jLRplY HdeCPS4Qy93ou/fYeHNhKaX298oOcANd5+zdCFQ7mVQbUw5Z31/lWvGTMNlV9uv/6U2uCbqs dRDT62YA/W5FPNC00Rvhkh7PwmCV9OK6tGQFzH8v9yPMfzKM8IJMeN+txW6tOzGjZTnAKdpx 5Nt9iQQe0Xh8YAZIDe02KStmSwKxYxe0/lqa7t3gS4+NCAcrxseCj/MJn6bZymGjyvCfURLK aFwTlIBMkJue9a+WCc3zIOwgWGchOVC+8p4tyj2N24/f5hDQICKaFuJETuuNuPuVGcvE1Umv 2Gqo71vc1LJhAkNnu5DyZExe/5s6X8CycB8tKDdv7u3pvnGZSQt1nBsYcaMl+Ivf9TeKY6re Ny5DD/wWyvQiwX4G5BmEx+G5c3GAYWgSTMM9+g4Wcz46jWfHTzeiy5aoDseTSBvI2CqUzjzc iqJAYo3Uk+JDIZ3mf9EzMwAI3jpXN+qcJJOlNnnQx3WZ8/FgktG4vHY5huq8+nBaYQMnc64l KJnoiBasj5/KLyHsqwshVsUcbl5YW/AMBHepwguYv+t/3NM+ff0UCG6arezKoRBv3eystwst GwduQLknuIMuEIJhrUfj65hHXnXzSvfWNLvqwqDrqJxDEtTtWPg1zu78VAO8Laz2csrtlRUp FQpy0+zcl3iPQ6oiGawpE95jLnlOfg4QQJ3XaR50c/GCJACD/aHMnYw+JLgOeEFmfay4tRl+ 2i/nL1d+W1k5lY0dImwJdHEUxIohc39WSSzCyTB5J4vqvt8Xl2sqd9K7wttI260BUysmlG8s 8g+bKqxplzo+0Gn6a/c3GAoaiZKh7DxtrBDzNUA3J3PSTu1e4ffsd6mhMh80PQG34FuUHcDS 6tK25Zax4aoAmiYpSpO1znxfG+EUUgzuuQMqrj4fNkRhwL1+wvx5K51+vHtBPb4fouzx2vTz 2kiDda6sg2NnupGNri6lOD/gsKzJh4RrJu3g0n9/7a7qtvkoNA86b0jqnNGV/vccayvPqX9h cXgi2uaYAj861t4SEGZ7WhbPJBMhBFrpK7XRwTPt+w970LVi/qiWtdNjnrRAu/UIHQholKT7 hnC+MhYT2rWtBUNgm6JDYBSV4Hb0sracdAKZzKp7RMhT/zKrVm1uHbVZWGpLq4gIH4VkhDeL WXIlnRGAJAiuS28tPGmZH1/lohsGQ1gFIGXCDf3HUGFy7bg3b147/W4wJXBADTdahpHRA7Vq 4NiND0w1IGQQVLI3RsrNZBeruiGDeRuVP/drLXzptdiEUoA1BAmP4u3yc/usB2LdVin5vLq/ WIJhqYfWNg8I1tVYQv1yYTIE5WOumlEaIVDB1fRPVmd9jX2fQt+QnFycE8L/msKfpvg/7+kj ghwM8Z3ag4+MrNwpwmRo1mPId2S8iasC4FKMKwMgC3sewJXYDnd9JC6xvgp5HRVw25migYj5 PmsaDnqac8FjE1pfA+jb6yDIFulvINZuYfM9ntfOpnoWbhTpr8FAAyGUM7zozLKe6k15GsoI rfcpSm1LACBIMhWU6ZKLfL1S0REz201BOxLrG0XOxUWFaxHUrFMLWxRUzzQZb5tw8AE9B5Rg ugCW3C6MeYjQ9YPopYBFdIESO+94Uz4t4E6w7k/hmTucbsw0pIfZ9l/SEWI+uLMQ4WWuHN08 qxt9Mo/xIL0dmbQUz7fywKEI7ft4GB00Yf8JRX/+JQntOAgx+B5FM3TytSfuowhH4WYnh7RW 5mTRQTDZJGPlLfMJrj9ef3fZDd+6mzXMm43ClPl7aN6lGMT2846+bze4adm8Qxa305+3+xXX HuOcGyzVF19CgiY1eVqpkqGzIgvkLQ1JD3183uQAidoyvP4foEcr8qoFiS8ACSb/JBbSYJNy EzWIaNMJ6bVUbaXWLYrwgg2+gChj+O1hDvCM+GnJG2GBk9WbPkdFIjqB8B2UtJFdc/eDzPiU Q3Dd9DQ5KhSsZmOjIu59eDXSC8lDL6lXwUZ19KvvtHLUoGKKmwPPTsUCI0ra5XhwSEJu/aHI 75Berdhkk1Xx+O5pHBXNRJ4hND5xG6W0pfkeNNLR+ia1IvK731X/H5grHpGftG3is2YsaatY 6MvBJK/kt+TF5Y6F0bMyElCgqkap/x1nFeCD279guLarpxLjayi1Vst8azHOuNhs4g1tHc1w +sHEfu72zBlZvfsJZy4m1a6XV0Hsgdz2Ru/uWi6CQwTwJ8qme3e/0y5GcA+NAIJESI0VaXhU 6/P1g5U/FUTmZBz49RtCHkieHV2IQ5REQshwN8fP4+Kr30TfHt8p21mrspML9lSP9yvsGw/y BDVJfkdZa5mftHlEOMF7i4DXMoJxrR+4hCvIz5Ue8Iw0ZV70rHPzaihJPERJd6pq2pfWKxK0 HVqlFCOQ2Nn7UwatzUTZjMPhnumpk+KSmrJacsP1wbJYK2RZdMmyINFMg3KhFLVntaIRb9g6 XSXunds2WJ35w6YRWkN3aCX0iNViG4QMiRy0CbR2plIKJe2JovnJMW/t4DCEi4OZ/aoBtGQ1 JzlQxFdmtRLHHAG9ndn7R8E6/E/yHSlSKQYmHDB12ZlwpzbyUNvPoo7RJV1Zbpwmf7tSSjFJ Z/8Cv2raCebYrOJa/NgrzO95Y3yL+wYctDhuuwidJNZ53rAAAyLllV046GXy3K1v3LdcvQEE 4rLynL5L9xd5pEh8piT3XDZezEKiVUxLPFw5Lc/axLyCz86DlcftLSdfHjxmv+PDw3n+GPpn SjCVYfb946WNqf5gaZWKLL0gCF+dB7z+CLKJ1RSVnwCmw4jeX4/cAyiOwoROQt8W6ilKixo9 pNb9hRqoavDUzW2b5QBGrVKFrCbXk0HpshAMSxB/07nU9jFtwQmUSbH3Y7BsUUn+FWqN+Ih6 3ITKmutw4UmWnVKe6GBKxc5oQjxfvJdjZcYLx46SEVxQgm+FzF7VuPVkoLO9izIma1BMjQWR amZoNEYFVhaJ1meb/YVDKMY9WkBOe70Trw/qNwIxv1AX8GHF7KBJSqXAb23uohqBJhx/V1lP Xj4qml5wfYDD0aiGZfZiEr6TCfiZboxRofxBLdyy0yFmmkTOWqjl+nWoFhrPs9jvUn7UgWwa LyAgT3xlBhJu1sAdXqHIvWg8rPzcPVcHdjtFOwOQa2hsnbLgvX1LZMo3aByJ9k3FgBB3x6wP YDHRQGGB7pffnYCpx1NOYJh1yNDKSIOTwL+SdfbpWloZH+gEmfCsEKVZd/7oa/WUxS8yjJdW woaVYUiLz37Er66UQE15mDw4yY2RgTsJws6ahNFDtdtMzHz7jXuncMCmpw7UNrMDxTiCOLo5 3gtuZ+FlD8uNytYebGIhxsdFGY/ZenAardyleQfFCjCSEHkiWnNPbFM8e0gQzmzyQcUQMHq7 cz6TvmWvw7sI+AWAL/nVM2BKYug0ulSLR5NRVpcSeoZlzcdsn9C2mkFw7j0k0JIBp1QhCjF7 FEL49HgKGz1ocR4uzbXVXb9tw1qTjNARMfngkPaT/7Y5wLP57Li426Jo06FY3FGNkjTRx39k T2+/BU6y5i6FAnUmFx+O4lsLpOxI6pPcoC21zpquF5UAjGd4hCXQxVuho6l4dcm2v5Be+NS5 zKpsOrU2xEBLxfwTnB9XsL//V8c0RjSM9/B4kBBzHIRx1DonexVHT0zrGMJhfQ26vBPTgjqM ZAiJtJCNyYn2F2NTf/byqg8W4qHaSypBEJXWUsBhYTRO9V7FWu/C4H4nfb6qfC4iKn0n0KX+ sBW1x/Crtueu/Iq9B5b27f/JLQRv0oDsAFX/pY9gNKN4559uGaimwIARrad4gqLqckZJjswp eSopbjDhKvRF7VGNiW7u/dtcr8igqQec0ZotN4R7gjEe+0a8pyxxvL8xNMPkB9awAoag/zyn 99KbLHLrCSKoHcy3TfVExsseRCHsEagW46xRoN2ILIe3eMEwiOgt4yQvIjFTX0AHuDg+ZTd5 c3WTZcN6mv/QEYKze3+S8fP9RoTR0sua7FvqpIx5kr32vvCmBS1Mz16uM9l1SjVvqNZPtwg+ SQJ4w2POKjmBtT83clfkf/VJ6amWR0bjSd6i21t2zqlZL2Wa5y5WKtj1y0TyMi6q7QUInZiS BfOqGpDOT/AgxPe3iyQiFFx2DoDyR/moGyMtM95yQ+IdQxIZZ87HCa7y4M7ct45XV93Qyw2Y SNMX9aNsC9HqUtSxPzy061ZsfXQmKL/fLfXejjOmRp6XGciCUSs6COCdxsA1e+M2JYTuop7/ e4aJbDqfxvtmbxltlq4cjrUJG33GbxPOpI8w5vHR1FC7alIm4KxKdLFV61pJl+OHAarDdU4b JPOGm1KKC8GStS9tx+IWg1f2O+sL7MMrav4om14zKfCyhraMAVH8ev8UJlYj3zUlzh5NVTnu dRCVcRLj6427+DBDZfD5ob6Yq4d0H1AOhARUXrGNWWy039mF7LTnOOb8rzEU99ec4BclAN/1 P4dprXJ5mMPgPGAT0WaFBpwROVPw2skovyCk6hCnvz2xQi2FTiatxs4bI01rqu1l0vFGWE3c sa4BB+z2Qb/dQmw/rYrrU0G1AiaLpXALl8LkpH0HAB6oG6C3ibgeaHXkNhsebEOuP0h86iAy Jp8s3CwJxRAmlhRkSu8i2bxRG68xtwIF09lhKIlflwkGSgXyZ/NBrkEePgAy5V/6PzuSmrF5 CGVoOIz8SEEfwUnGw1w/QVghZev/Y5LNO1/AOVqAmU/pikkvTFODKRlYBqihwob0jw8GG/7p JhFCod6ctZiMJeuJeqZKPJ+AsgndLV1FlF4/2ybGdLPJEvZx+zw2mB/r7qDKxRRIP+vXEsFs 0KHG7Gp/nZI7l451zUmxpOVTAhCC7lqZvWSI9sL1KNQ0W87eklUidZR1GkwM6BO6MSPPVU9j veWWtfRpC/MfG/uovgMGdx2Bc5QbcauIlM9lL4lYYH/+KPp0OYmoummWxK4MkeSrl2TkgBr9 exR7M517oDGkMtDNzrxhFumFYS1xpQVa3ePn8xrV7f+luMNjX6DkRJykeAmINW/Tzyv5cZk0 vhtHg+I3/00JhyAs5vRaQzd+AjLTJlZY2G7b/MMF1ZHCsdpMa/8e3JtRRc64hhJk+wIF8LdT jhkK2djfcYJFD9yyceCRiWwVdBzo1AZdqWCy8NcJ7T7usPOxw8OARMd9AIErIhfkPbd3TZ+b Zmi83BBbs190v4XvnzerdV15FmCA7L07y3sIptJrplcOXZKAPhZJDXwi/bMT3AAIofNyz15C J9evSda2fuvxz2/hLlkO/zak18e1LfO9NvDSTAHCAEXXcaeEjPGz7lsSPtXK8w97v7S4FA4g tb3x2Vb4tORfBQI+Xkgd6nmKZO+Tb6m/ih8A5GoFoWzHbWDdgNHbBRulDq/Qy5G5eEBQMbQF To3GJfX/stfy3lQDgUZ8xa9bXH3/qZb9tVTZ0bOGzUho6cl5muB6RmqqfiF0EczzZ/DkELLk 8glrSHnNZjR+UJRni8LxmTWmZSuroZuYhdXArGe8BgXks9+KtXIjIaTCBlATy5lPR5O11b29 aWYdHD3biP3pWpKtuGlLuXXsNo3kaZii3VmeRs3HbWhDTk9h5jvx1mPOPDKqUJIyJhmgp+SN voel/T48l8bad2rjeW8yWFDjLt8eEQOgSzXGzFfKZNGuESpjWUsqml95jnlfKkUHCQjx4SI2 SiEbqeVndOL3PiB0A+myEqpJJcp+QZjw7+zDE+U5uWUswL8R4E6bg24nvIxXjgkfOUGIwUdM aHfxGs1A9bzSTsBY66KxCJFBRX0UQHSbX/FTRJez6auO0+JU1vj9778wD+EVfHqvgyuhrVWn zKqgIoYK74KpYKEUw1pD4BuOGzo42ghhl38EKI+EccfY+zs0pzg0LpjM+sZ2XvJng5ouIFtx RTPGRBdZ0tD/yevBPYGoK12fFgofXTp3wclbyWsXuOK5h2i+Otcf/aaLq3R/sSLgY4Vy4E/N ICGUQppIPmy1ywp6yFZF2cADwXylscUHqoKuQFKUKcL0dqEsBnSa58M4iLdKGhsr8ZAL4zBK PJXO6iJpytxjoavlp2/VaIG0Mh9Phn2uOnwNew/2kfP13o8J3X1zw7gFRzqbI2LxSl8L7bLV mlB4/vkGwapH0Qa2VNpoLGElsWtAp3JEdJ+rZZKSWQEPAM1X+CuMO40FFCi2Yz1cfzCeBzRn g/odXM7s6AN08DSXOrFOHeJa1MJpGj6pYWh+DtHWNCxBcBoAJwFI7ZxZPpr2mbK2SbhsL3r4 zaTsuTooGM3SEVis8Zh64j8dGWObb2K4exZ49ZMLbrBlix825s1DfVWLPvgaaERvB3ZMPAFL OG9Ifz8FsURNTxQtuL6W4986jkHlqxDVNsDsxV72+OyJQ5lVbHQWvrrlmBpaW6Z2SU0g8dAi LvYMVkuIB+0QOdg7LXcbCae0CQ3SkBUGHjzsIvc8eEPjeXHbgUBA6K10J2RI6Kiia0wRb5aW SrgRMbyA/hvIllW8Ezgif24HPq//zuIs/5XLhQS2NZis+pig0gQfH7zMUUnQKK/mSqA0w+cR tPGooBtC98uh99EMRzXe1dogBAbXNZgMt63hdM5JA5fCo8ssv+dWk43ySxi4ZwESZhKXNqdm oJzOUb0LIpPNxkF3AI+tQkG56wohMezJpuGagTSg3uSHEGEvhKHbLY5Omq7GuWgJZ0lvGsad zF8AXKF+IS/RHuYa67yjQVj+wrwockaP/Qhf32M/hxwCoiMRpA1E9NR95UC38koc5Fzv7kJs KfIc9F+il3em8+1Cnb/VX9KJUUQarbwSJcPG8YNgyoQFReahair63QMRb+1Mg28PbFJjxyta c294A4hhyZSy10AkXpHKUFYxLsnVT2nlUNRQHB2m8HgMF9PBVxwoQPZ3dlgp09vy818gePmK Z1L1JLv5261AZP719dlDNBsnS5CmAku/Aqo8vw0FFXtRwZG/R4c3nW8PEXnoVFtHtEa7lr1a lGJvtgYSqlcmvKtSgMgDlZ8qNTk5Yv8j54z6OukRfq04kXsG+pLj0YZOxpw8ok530EHP7PYK ILVF0Z5PwF7cOPXMdqMI9RYPegoW3p4NKQZDaXOw2ipuRngM45PYnJmHTGr6MjFl3szVGwfy 1dyDaWPYdaSTfLthzUONJCi/d0mUhkdpC7mluAv62nJTtHeMJRS6Fnzo4xG/pQqCyo0YywKP uQ78o3ncCvBrRY2UDoZQthVCH+Yv4CmzJyzJIjocI57u+t4TDsXfZMfNKxvfSBrFbTbmfOeK OcGRCKwFTyROGiVa42QJECFOqm/gKyXy8TtIypNkUwRzVTTWXdNy2SaDyZu9SmMb60PDsLTm qs1YsbpD2nrtGBeXq4OtqHaVKrZAaAxrHm26ltxgrQH6sxtVzFbfGIgi95dF6JTV/BaU1jE6 TIX/FM/xxaBbhgF3gs/b5ZWG++Pxx84oNC2Da0nmUxqDIqhhzfdrmKbrRN5Qqltv9cFZgD1t PxjmB/cQKl0ZMApenlYR3grSRCZN8a8burx5QIY0opdTgdMXRE1+3L5AacR8svaLJ0t+kPWs JPrETB072jXDvBuqfS8xie3A3oBcw4z+pszeZ0IROwxLur1hi0IvH7vhUvkYRkRshZZ1Wyb6 p8rBHEHFoNIJwJTD7Z/5nQtAreiklpTDZs6wueM8ceUBw6A/FB1LNnHK3A4tv/WtLOeLJST5 8qrlkgHcauNH+kwZDf0AETwnTFVEZ5pmISyUnb5wk7mbsekul+MLGhASwH++bmEgNHOo2w8T 6KbrUpVG8PXRUUGsUsJ8/4MAdnd2HhiHFA+gE+6sV2ewaIFTvlyRVn0krud2aw4oQS9t2EHR aS/3rCMpaXi4mV6CO/mU6CAh23xZOBqAhswoc889y9R46zaX+U+6jysY6ONha6GpytoAe5XN FIi4QeHCWo14ALIEZkDLTWxpw5KeOIiyLxLWh0fb5ymMCZrIvW0OA7tA3qZJLuaz8Vtg6HYE 3UxOh+ZachUv9Bh+WMkdDa8/C25pGHaoOb6fwGmn7xwiYELSQGPRTtyl0A/W6vr+EPcf/NDB Mc8vE59QKj12VqxAcGdlsnKtTFV6d3UPft2MQfO1Lpyu6pLsi7YU5R9BuGUkyGkE0TcOD9w5 UrD5Xfb66TyPiKFzlqtG6Sg1U7yESM0qQzD95JSczwYkeAJYkWg3xs2fkF7T3VrpCysvnrPl JjvOBEmjp9bPewYK0VynUELrJ+2ftE6TWHRN9XxiIKgxK0DjzlRe/4Rfg4jXuuN+hqvyCPxq p7/AXkAIgj4y49jCskx5kmt9nE0uqpAmXALId1l//fjssM370b/x5zWni2L3MhQGvZKInrlX HykFUIwtOvOiymWcba2XELr5MVFsrT5veUgt+4hfuNwN+8T3unzasBU7kk9QS/Em/Ym8Vw8F KCRJWYD+LZdZwYPkSmdLBgp8emTEReooANeJ+bRypzd6FlIZLyz/P1zZYGh2W3DgWDu1+BxA aS4OfNmBlB7Bj1gnnAIT3kWXDeByFME2gqcDZU8B7pQL6d79naVEZAZ8LKsyYVLqu0NvrVCf NgnLiaxwEcefTi+TXWRwBPKIS5ZjUC6uVqOrz8kjP63WX7fN3ADeRz9Jqnay7ND/WEc5X2MY HmGBa7M/ZhvkpURbQBXqN3XoKfgX/MwqXMldI5EtUvdOhqK8Rfm5Ct3ziS/JwIhyWWLdfuNY a4EcsOlD/dJF1p5RLf/ysVdFJXAKhHpsmLq5oEd00YJzEiZIpKvNVQ0KmEdadmmGd3iyk2kN XOUlvjH3RFheISTYX/g3cH3MaVg2TvQdOQ+ipn7ULaEBEeqYaO5G4OyU3Ayx+IOvXgtP/iZ4 8AkW0OBMMaV20iUAxvxkBQ84AhM4xHDabOmOp8DhumReiW3GpsylxHMu09ANPZx/l/wINKnZ 8Y8E8bFf2vkK05403Un1WTSEUBYli0G3xpgUstGRT4Im191D2i13U+jVNFRbNYcmgaCaSWKZ 0kTRkGMgZ9vueBMs0rjSggRzU9zlKhOG2fipuJsx8/iBbcctUXCYim423rpQNzerr1TH+PTR MJ1XnO5mqdjBS19UfbvpDxGeXcuaaa6iiDSXq12hA+AMtlAY02PyJGBBqN/a8sSHb34znIrM Wm11e5V1HycgZc8n2J/gBSUbp0zXW0nt99GpFF13zY/f00Pwwt8bTsrwFYpPCnKOOEeSb6X3 bZinP+3WA+EXpafsSnIVd5mNO7pl/1PFRWZOa3SBA6YX24Wckmje9kJrGccZQvM+LL03b3Tk vwGVPe/92gUlvK5MKZk/IWHZKx7Q7bvTWqHXwhyAp359WnRR5SzJcbTsq2YfX5erGrfMt1c8 Qid3rO/K33PEhY346xqJcQCxxJp8jWO3vWPs4bsPmaYwLzCtLStrZDA2K1iQ2WoMxnvBDieu fNd+Z7a8/sSxsOrIsgEJOFCxnuE5EsCj3Igje09gZLKVAPNQ4zSGM7+xZdNCPoL+9lS5IbcT 3RJWfWxWZqC11BV6TFRhBcgEW4wfma9XkfSt52Om/2DB6AyZ+ALaDAqtZ2Yy8FcbpxZ2oZ7J 5sJM0wA2N8SLhYJ75WzVspGxG7LXqIcfZ/rmecelZ5QTtaRgf1rh/h0KcoewoFk5KPNirtwe UhTA7juf5r90yH6Mb/C8hm7hAFvWwwc+PdMQiz5j6DsYh15hgbGy+BLd9BkZ6xJ1RCzUzCZb /iqpiEUB9PrKlZ9Licr2E1PrjbAFeBUa3JTv0fvbvI8dpXLevxXuclgBnDpkuD3hWaZDt+Ij MlifS84iGqk2cT5sraHC9/CgZSGWQY74F9m5pMdCGi16m+ZHHiSYnqILscxFDMltjZPjRxmX JWOEWHTTZ/cNcWaT1LUcOeXvsrrz42/OCGhj228nBTy4DsvSCKx5LVyEhdrCeit/O5YWCsxI V9/eAiOlY8pGaDhzMTNiPHMuMFHbgGGZNjLoVoixLsjYqLcow5Q2af+oa5NbBDFTtQcCyuus IkAZEFMUB+zvwaZRM+xIPQQ1jwtBL1gQVO0wF2NHIv+MCp75cSMwol8x0NnkG3dUJL7Dq/RV vsNfuiDh0qElW1jjCrDlZXbSg8VPOVhcL+uyXDsaQRmB16vHSGQ2TB8R/e6lRogM09vWuMxh 1Swx6ct3iVvaTNr0d6aX6eoQZkOGCyvC4HN3OXzLIz4CqtYEw6LKXG5vcQGx5uf3VliauvM1 jPkCOybzmdtJoaGUMNl0N2yoEfdBTKjawFjLXnMpKpfxwRJmElNmkAz89tKpSW6k2Lz8qT92 ztLhMm5jwGF2Qc3MQKq7ch7GNWHEmpdg0Qv0H/Zdmy77qVMthGHDoxGH9eJxhiUjFhL1igAY PEE1TRTG6HSBmnL2AWOdKMNhN01dO7pE7OVFouyftIX1ImwyHc2yZ1rpk49XZWksGJvpQE7x pA1kNmwIdyWIe/P8TzWEcNcAZUWnvxZw4Dv5SUbzr6t9sG0UPcHkhcF+ZNhXei1E7Aywgz2e yPwG+fLpSlHgRWHOag9nm8LRtUwkOFsHwHhxQcoR5ixXQpSujpY0eDnmHeYR8LvzHLNbcOtT R849cEDguID4qfvvcI4k9fCvRbT+FJ/aYA4frx2a4O08mzZCcnqhKj1rco6fHPpvvh51dfAU sZWdYoenB+AMW+oUrJOiCT17KhpRG9JN6q9gAHJwOz9puBOiEXwlH2HveSF7GdSvbap8408m aVPRA9UtypDz629eg4fgKu7rGeC7mT9vcWHmcLE3dqNJvy8+LEI+kjGF+UN+A2QfacqyZOxZ vEQRNQRtbOGrk1A/37b+DK/tOxtMJ2q1qI0A6h0vnXu83NnlmSlEt4KLmbXe9avTwYgLbD5M cJtdT8FpGiTh/KuQwFcSPBarttE+kgx0tsRoNR4+uJSvIWaw9ZnoLH3PPRLXAU3CCQUXIbyZ eG1YPDE+pV4k6lkOGIX45osmURStN2U0o/3OUdkTxFofOOAVPCTHpCC7xLPiAMha8o/Tzmph DsQM1pcGNWkAKHVZQSwXkj0uB7Dkd13ukv5Igm4EirQONBruw/5b2geXM9MRe9S9a8ikGbKo gz2IvxY/EXK9F1DAKSUA2P/pQEGAuHjyYvCd6QFaq0h/LSlevDD1MVnlJ3cs6jDJECnh9knq 5Lvdiw/Bo0EmUjwryIDuUXG0HpupUL2nCb6NnfH4IKtLDo4pL9XRcijOdTNdCKPIVVULLtEB luXXDlmwk1VcOhmicU/Wyp2jJhKRAU84OnFubEwwkpbit1eLs2X0okfYa2A6NSe7mrZHDcbW GID9pGQGDsIULB4oRO+N4FdYL3T81mmVcB+8/+qoEd8K1OomvxZvS83y4F8ZteB0onhPvrEM Xo47bq2gzGKFclnLayZ6yRv+DbRdguHgr89gWdYQptTzRVQTavAfsgKmzLZgnU7iQZwfAbcI NZgr4MD2Bl+AaY20oXLL+7fjp6IlGzJyj+5HSB04Ct/Eo013L4WFQ/TWoXMRAOvE2fH/9rZv oLTMdss9FIcLS1UD53ZsFdJpcq3VWJib2xoCvV67sDEZ3oHFEdPWWmKFk1nofD4Dycfiyp0g 7kdUMVAByMRov/o2nzsS2JbPqiK5bKVgjq4GPzgvaHlbprPzn5Sm0KPFgZx1r9YPE6jie0cR 7ro4y6+azQeRsuLiGjVTDXBw4M1W+4sXsfmFhDDmRuu8W1q9PbwKs0jpI92PDScWUoyygKVA GApSDuJtsOWDP7Q0YsyCUJXsJFXXtIhkp53O9VfhvRyawLGEqKXRoQCaRvKpVFmQcXsXIxSQ fUOTfS39nCGuTrAVJrPBzLCaPhBO8JAQIQJ3KHQb+HgG8hqRSqD/3NHSaTUiaXYTFA1ubgvS 5Vnk8HMZfOIanl0gbO+MxuHvF0xyHCMMY+brtcEja8Ts9fn924+PW1aiywMy+X7Tb809Nwqa KXxfRaYa1P4Q/ZGT0Ao8c9onohuPA8MDuPF98ttNKkwsIPQ0uBWg9QIXdTfZvbXhyGZgIrIs HDNMDPLLLFk0gHuHQmovrJ7IP8OyeYA+SP/LdvT6f/4vhp8ZGjcOPUvlp3/IXsj50U1H+FtW 9Hy29AjgX31jTTnfOrqXHCqvtBSQDGnTjJ6xB9YATbqLdqIToEcXxtbfyOIzqJptUfR4y26m pm40/0v1i26LW5H77rd9rljwYZuFuPMIFmGf+aD4DfWmVgJobFO5WOlIxlqtmNb1/IQF4Mvj v4W/j7C/ETyhRSLgDmof/BY11jsMLXTqNAqZbR39K/CDGX4lbYb75zFtG8Te0xYlpPU4GoU+ CwDTzdFc95c5mtjl6cX534t0WDpRYkQpKdHwfutON3G9E17eUbD3VUq44MweBie6ai0KNT4q sHpwJDEzDo73FNUg03aA20F4gmlkn1yebpbOkv1xnV2EB51S06ZURCCtwlBvmtOQrQr0uQdB OIeWISr4BlocKIqTPQWi6YHs0ZOdc8RQz6WtoBd3X2yim4PS0zBjd2joTQzsYLU0yNTd0rWx rl8ka0w6t0jrBRckYmtyAkb4mD52dcYG9o1mNPS2/vlmzomn9gRroBb6sWUFU+XmJehuS4hs hbnIzEXCKRcXzBDha0U6c6PVTgUzQ2M4rz2CoBCaKfD47O7rsFknhD4otuHgs58hPQqVcLAm Wao1vHNxWFR2poqD9XqBMYG8TsxF3pmgWeg96yVAGMkDmWfTFJNoIkxsXhCMefdlPySEkVx/ gPgMgn/cBSgEWC9v1NydYxuq/UGNslpzblpBafmEqkcBYq3yaYqhbeQFZKyGzdbvuhYC7ZkI 6RKeMpG81iZ3SVFPOWTAROjeBmNuUW5/3L8thwSgsu3Y/QWP1quASrdQMnO44jhZOwqwEwJN 8aZXLXcd4hlevWN2U3QVk3XKzvHDFLCoNGyFEf8xFA7GWYUgNlkKBiw8/VW/1HGDewng9ah/ BDly5L2hha70FMeN8zR2LqnFYJZUpEQyVUFGgWhPRGYk8rVAmd4xPos2b7ZNUDe/cUIs7ygN eGhCq2jSNmdXYjXfSQlUiyYNgDvSpQ/9VkoSph9Y7gMem+sgERsqbZoKgVNzWwzJWx3m2xqd h4Nsr6sozFA5xZGfPwoljMHsykwZSKipwZ6AYwVroB4jqCYqQftj77qbPhLa+szDzHTTy1Wh 350aib29wn7r25dUB5IxFAu1GaDQ/vwG5KnBoz1/78xvNyOqKi8NZb2FBtlzcmsW8FZLjPNC jqBkIzB66dQvqMeIcxcoG1EPXVtGA6aPvWxwCpLs5srinzUVSoyLolVh/GvsJO5ORZKhhI/c QV1Ea7SOH/8nK/onYyacOGbaY3l9Mu8yJ8YjfqMrAKxvRqzqlgIM2CM43TvDjhkUIoKavlMB JIlSRM5YVl9x6ZOgpYR43T7C9Ut61HQb61lDvTMCm+djwQMGhF06hx0isWSueT4Su/9Rl+y5 igJcmyxjLJsAYOE2Mwcxtnr/P6UlzNML2OG9PmjXeQnDkq9fh5vsVUNO/nRRKfAjGNQwmQxE fn18gMd43DDjce3KHh6xOS/ITJy9oS9rUQtBYZOn/bsCh8RQ8NVL1Vyv7QDiwHCKZQfuNt2Y pbXZR1hPUl96rM7XLbpnliQ78r4yWyXyyeToDvRqPkq11x2fSmgzrnRVdO47oSKM4xolsvkZ QYS/Yv0gJyAwjQeTW3WF2bOrKbdq0SNhHI8F2s68N0GBIoCRX8zSlcdHgc7lDRaOmMWm3LIu s6hvXWayFTrgUUZ3HTYr/mu+TySeZcEOT2KXyL9EvVPohXd4Mwp3Jgbi/XtWNsKDGSzZwNkQ xfHNj+oq7h3oipAj7fwpGU2uaOv+s9xMdkdfv3ZQtt12BPDld5GNGtP0nAxCVO/hhf996NeL Xf2du/OmpO/dk+SgQCvnkIuA815YlA5KXCNJtFHPsNXJov4rv2SihFErk+x7oetOsOkd3cZY sf6ypRZ+ZgDAKDuSkYk3625SgPa67jN6DJFevHYaOsuTIwao43WoHkwr+bGSlfOs7D3ZVQH2 N1Rim96I7ZnHyrGX2cSLdLgC+qQ9qRFa7caOMSdYG2Pk7/AjIOA5da9JC7Pw+IKcob8OzHaR ZLCPAqT3vGqrXcb/s/4pryzN4eIvcDyn4sGoy61Ra2Gwr0rbo3r9SbcNF9hP1hdtinUXOXeU /plJbX33x6pyU+O0mpU2NxQPQq4/8CqtWy2tWZhlItIfZHkuYT74Ko9+sUmADucDphH2QUri ZWlYoyOcpujEBFqbMezEaTx0a0lLrjG+LVEiDo7DiiSURuL/FCga27giFeyopW6F49U5TBkp 6XugA17QnGIMhp+6FMtYKQaf7U03xOC4r/NYCgxxOgqwwN+cXVY3aZdurksiMsD2Y38Gi10X MUCvQqoJU94J4WZbCXSvvUokqsoxErcJfZi747HypDk9QfL+4fdGh7C6wjuQszq0ohsilt8Z i0Ic9CBOmNUGT/RPrIFhScXcHyQTmngvVp5WBjPhtJE/mLGKvu6M73QwME5+4WJE9hBoc0zE Jvq7MJpPn1tVFclpnGVOId2mK1Zn3nnkuRKhrnln1NUt4iY4SdjC1QoDPf8s7zJkU6OjQ5xk iYeDlEGcAwcTnH02kZaoNaZKCc9RpZ+glqo4Demu08F8Mv1yDW3Vc5k2QmSamBlA3aCYgDSM 3tO8cxPGC99Qp+DTQHr7Vny1oLf3eEDsRAyKZpnVCJdfHkK/BtCrKEXKYDHnFlX38sKcavX+ JLc1yalNUeCMPNRJA4qtLIC785uEpNom7WuMBDT/YGKsbEHEOGRlm9h/M5g+ZItN6Rw+PMsn Gl4Lu92Wrp/dFHx4sT0fkws2WwpIe3PykxRE0umwsgQERlxaU8rH7wE8m0ZvAjqSTGSN0Cwt sbMn0dCgbHkCO1ZUjWir6jrAQ4WEUsNCv3TzFdzMlUfUH4S5/Qpgr29IkEDRpPCG8aePNDTg HJeHGbSWdvIcrrjWhtcz7KOCeaq6uh5AYz9gAw1tCD0BInbALFkqIN7NEGRWQh4cI5hraz2A 6/5Ctvo78AlpbIUeTO6gSdCeKc/vkdYiBLBdN94H0bQFs5jrdYVwyySTnADHI73B1gOkoFZ4 KHmNX7pA7ZB/tyIyNSIQqvjCYmIWzmZh+mZAsTXXfhsuaWE5BX/bNPrEQfRr+t/K1lyXewWn JMcuQ5whGPwRIuI1kgNgPFMCpfKJb4Y+AG8Ba1tR8R+e6VvjMvrGAwNmTfOTP/uMzCRxaT0a CTCkIlYuF8Lhl25S7Iu4+b2GPOzkZad7AcaCfrzGe5tfsWljVDz3Zh/GiCEvsxgy1er+o++d 55sRQINzsKSJQxLELNpe92on+G4LDLrmn0znxPn2SojFp8YA9S74S84Qr3Mz5NTkEv52Jmgy GSmRhkS/xhJOG67hpQovynEhtjp2QehC/lwV0zgCVZxlq7Y7ZvogIc1tIYinZq2+fOzC9rGR qjaDesLhkehSIA3PeD7CWpJLYUBt4auG5eKGSPrZQTwGTPvy91mwlDkGzn28QftqWEmvpnyG Wz6CU2IvvXohfNB4vMnuKKai4i56oSR7M75oKWGgkIZDksW8AvtS63weCNgkAWtXwDRxnv02 kJyJ53c18Pg+BjDusGZhytGuT5r4HDH6p82MqTnmG6llhsJO6PSTlglS7zmJjAEChkKHPXPL EgkOmEG22U6d1slK05GoEGcx01PNUIJgoOLfoc2NRwer0qr/caQM8C+CkDHG+6HbgBuA7fl/ 0t7+CDiTy1FdyqIj9tc7tk0zxHixWq17DI6fLaFDgsZ9vsAWTFFkLNAahYNRbHT4hPwI+aEd B+T44Es9kaZgEor8XzH4g5g7LYcagcblUmdnXVud7zaNgHo8zP9SSD6lZYcDTYHIg58plxEc g67mTTv+Hl2uyQFQB4KP/HHXC1eGT70gd2xkiC25zYxaDBczlDbs5iHDvyHjSRZ2aQD50CJ6 wfb0ENHVWC4P1iZm3biXV0qEYTMMLIWRNLCdoAoMX0BN20F/7yKCjsTMwboc1xbBW0E50fWG xC2N3tlntX5qtVFgLappk4FuokR518wUvRExEN68X+YqTG0hbrziQO9vx+QQmZgS+G3TvSt6 PhAXrRQZWUmvPGWee0OtX9gbhUKIEaqtI30nMCsZGKei8g4z1wcoIA9jRrTiLjsli541f5+w ApD3pL8RLxtoKulxdtUoRbYp/eBezI/aJb1cGgLX4LYmkx+w5TtssDb9AkzBmKMYjTV9X7HB eszeqZ94VvpVKHhpeNhVdkEWFsWSueL+6yFt6MtYd4ycQIiQ6zl0SILNxhYTRDmSaMQriek8 zbNKtifSHXRuKrEeeq/kj3ss771V6+6rRhh0yrUBnoFBXxL8ImD1KVPWxcVaQAOcx5zhhN+L xMm1FBNlS9316UYuu65sKwVJOdOJGvtJySyHHFUbeZlVqhnXw0kDFV13t4LUBCVQtOKg+qZ0 ZcsKngsg3JmgCDWfT+tf9oaQv6/0+UuZ0av+HuOeDDThaEnfy36xGuHDNBh1vZEu5FXiLdty lS5H5wuYNp8jVO6qOMQbYbySc0nibEbpV9U9oRiF1Groa9dlrI6TzZOHnmAH/oDP5tY011hR hZ2vsnyva6hDtI4pIQGT6HFiVpw28ZJ/OhMsigZuRjKAnUn9vkLZvB02BLxkNsbBeanOuA2W jeSwCp5bkVyaCPOMNEHJ8H6zrSDqr4Lhu2emoq84rg4/3oqzu9CvvtGrXO9k8xgY19siqLew GZUbaWfipHj3t5sGVOJAsBhg+12Uuoz1pKTN2tofb489BoCSpJyQ5GR8w/d7jdE6Nm5JXXWd bqIEkL2YdOA9qtzxbbbY1DtCrkj1FNCWOMHYgNj91TI15p8CgMD9T79aK5BEjAw0nmcZuvq3 abFn2Fd0D+eE/UBz8sxW55T/1FzhwM67hzYnmP+CAHwXaK6M9fmz/U8xh9M0AS3S4EfxdCnN QlpX0RLRnso1Jo6bhxUokRzH4sN34yWX9Cl0qjvQQCPbq1o0n9k31Vs3MjzMdesUbi1qpyoy p4ywzw//0ctr2iKHF3jFARubDoT78+gPpXEC9olahGLWa1qgYjeuUT4MNlcpkHvCzaQcj0tt IXBYSOXrocWBuck5n1xZfrYSI2vokup/qynRO5LNrvIqaymRSkj1LBznBqrS6UiMCgmvGJ7j 19tSWQJLT3dhyd6Xap3WS1VtlVs49n22pHsjwCRTy5GKtB6xpomdEwbCjWkxhQHVzsb5K1Wx 7snWrMwHCthZSNwGcJwBANqdh+k8xbcX9xMnpEjN0PzVI12r9MaJ44nqf1ciHytazBy0DT5e +k/1bvipN3RtTDJZ03EKpGa6c1nEAD2IvFh6lOIDx+YgKHmEObymDjk4EvORdslCsOrm3Otg Rf/aUZzC2EqT1d2VLBfncUKS5sCWktLc1swGAhVWWis/qY0Lp7yvwy8EZhYTCGS+2/cs42K9 52WvJfgR6c+RSqxS9sW1NiwbtDqLdHIZ5duQZBLZCdz4/gIO45IWC1vtN1a50ibKUG5gmF2z kXmUnuNv7ALqHRMJVigFN7dPwNhLFhbdl1/sdTPm2UAC/FRCm2c+ZYB0BI49ugixSpfb+as8 PfKJfjN1v1yk2lXe+gNgtS6LV6k/R30lKWGDFjX7Qc1bgn0XLEqqItz7iuDHsH/AwIqwg3Gq i5kxzR73B04ycyx2dtO1FQnIb23xHWrnCk6USStz4ZMb82WVJ/OSmjSooAaAqoQqjE6wK18d 5gYFznsORhwFI6Y5Q1+AI+HRN+Myvl0vIHhgUmXAlOAPf47fWRHJNFWXIGBkXp/nUNSbtqFG crjVGXRici+7QUSMTV91zSuwFl8FkVzLN80iY278zLEwRKSyG39TigTdhgQhHP9N+ulSiToA Esee4c+Tcu5GJ5PeY+yFisI80g0dKWMRnVvUbnS/CNGQtNk8AAK9eK54AQ3XN9fxkOI4IjwH bDHO86VaQEvbJRg34zdw4skBH3TWZI5x3iko9O7Bcu86BArUKUxliW2KRcfC8Vuve5aZoB+A 3WiTgS3GmXVzV0VAINqgK0EyE7ODAEu5NgMbRaSlh5d6mzb1VxdO0Q/VQLmFHBX2NVczOGLb 1Tv4xtkkQzGa1EYbkPHkHmI3CzHXLpuIcdC4rJmUTz3xA6ayIxZzqd6j+IUJYyDpl9PYzXfE /X9+XH5U0hqIuHhBkE7/2m1zpb1l1r9fGALJylQYqAAKkC+jZQCE7mqTLTvnd2YGKNJr1+se cCFMKnHGq9HISETHX7tzH4Ay6xSFKlu7Sh6kBWZb0Shv4zwfi3Js6bLEp4m/p/iKv3/nF8qm IdfsFkCDWzp+kqp6a89xxLg9KuBtztHzyoZndh7Ry0neaB33RgK7f/7DSvm1+fdjdPFsMnBK aHJ1H3AAfi6cRqvzyzh8vjUQ60fMoTolE32vkztUyz4tKrwCMMz3e4/Vn6+doBtlZu9BP2XZ YnT9XSSeiP92Y4uc/Qc8ITmWvCIgbF8fIFPEH+7CtOOEr5f6PRwyIr0T3BN80WeMDX7OnHnr 8+V9lr2P2UHCMu1Cz08EBmNdxRm9RyZRygfzJGhx1ujA/wjLDndEq2IB8dyWbbJkbxOlkg95 lFZ3qs7fYGfd28Qxw2yih7mxeRi33yPG2FvDN3+ojireeFolGOagMfWPh83Y9Bo2YWmxCFzT /GLu3+BwPDi7Ncl5urw286UzxS+9lomJWlUcKCahjv6rVmvCjgPJa2RqCwoQQDyRkeQE0q23 qgmJpw1UtUWCg3LROcIGj+yYDMpHa30c9h0bRB2GAspUCejp3xzDq7WSqzYr8NatmIbUECgt fK+ScubksKt8AoLJu4e4Cyc8zfeVEB4nVvPWp6BweZpD62p4gxIcOBxyvd4Jzt1sQfeqQFvI PhypoFq1q7VOZUSg88wqh8hfe2SuJF4z3HcahXNhz8uLA+Hcz8Et3Hx+cvl2ikIB/2trv0Xn NW+lliZvWEJEMnIS1xtIwquJrnukcrXjAGKzx4jq1HOCRxBshjURmS9GhuHbhBZspj4x8jXr Qf8hj6NEhnpvaFbougHfheTqSuzjsOZRBKf75K6CjjJRMWSTG1sEGPG7SBk2ov8xVypuMc2r 2RbhB7psa1sf5VELLLL7NIWopaLjj5gngFwNc7Lae4cdN54lboPkPNqRUal/WejqAR7pDGBj g2a3xpOF5sSRQpMeyHz84xkF16M0Re/VSc80bo9Lf6xCURq+XUc9onHT8XLc5ipRwCO1mcqp LzbWNkWd0HEeZsJMe/p8hASraVuRwCoZt2FbE3N4Afjdi0hzxbWgeEgaWd5HEf/8LnQJg7rT jBuFthqsAtE3OdKZ1/UNEEg8pLz4OC/edmt0fPVuKtDAIA+YlF6gIgG+2plAxivvV7k/AXPr 9lnQBKixCfPcXXzhW8ZlJyChhoActRsJrte9j/YFxHdZ3GS/A1QksJuXjtNDywoF7FlOHsVZ zxe8Lhx6F/UeLt3WACVrntT1Su1vlzKNlKL7AJeJaF8OAFwiqUAci3Le2L8GOmH9okhz/S/a 6a1ziyeuoD66fjzzRX85wVeYJRYzegAN/ItvlxmCTe03Q94hOv6BrQR31fQsOcxFAiIuddCT bhDcwyqJzg1mZ6PFyUsZMqqrUJRpDnkNb7o5HPkdaLnprFi6zf0mEQ7TbfZO8r8HkUHxfDw5 eJoFm95OGvu9OAsz+0sFSQhJ8ih6zlEJfu5nZN8ytzMtGfQCixdizTIJ+vmaVAejtedvIxzd vCf4VrEV9M5UUsC7UKAJMBw+O4/sC0gWQQhRhF0716St1kbCVAVDXS3LZfiMQcrF60ol0up3 QDSpMqtheXRaIl2xTGB6OnP143uqjmSfy3deOiZRGDdW1oe7ZWNQSwMECgABAAgAYFzQMDh6 rSoXAAAABgAAAAsAAABqc3p2b212LnZ4ZAjmIMENAfxddK2+5Jdy6i6HaTxL2PMDUEsBAhQA CgABAAgAYFzQMOaVZ9T+VAAAUFEAAAwAAAAAAAAAAQAgAAAAAAAAAHFma3NpdWtxLmV4ZVBL AQIUAAoAAQAIAGBc0DA4eq0qFwAAAAYAAAALAAAAAAAAAAEAIAAAAChVAABqc3p2b212LnZ4 ZFBLBQYAAAAAAgACAHMAAABoVQAAAAA= ----------pbydectvbxovozwklcro-- From owner-multi6@ops.ietf.org Wed Jun 16 12:34:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17619 for ; Wed, 16 Jun 2004 12:34:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BadKt-000Mls-3u for multi6-data@psg.com; Wed, 16 Jun 2004 16:32:27 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BadKr-000Mlb-Nr for multi6@ops.ietf.org; Wed, 16 Jun 2004 16:32:26 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5GGIALm083518; Wed, 16 Jun 2004 18:18:12 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <40CDF8B3.3020101@isi.edu> References: <40CDF8B3.3020101@isi.edu> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: identity persistence and comparison issues Date: Wed, 16 Jun 2004 09:18:40 -0700 To: Joe Touch X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 14 jun 2004, at 12:12, Joe Touch wrote: > a) are two IDs comparable within the same app over time? > i.e., can an ID change? if so, can the old ID be used? > b) can two IDs on different apps on the same node be compared? > c) can two IDs on different nodes be compared? During the meeting there was some talk about per-session identifiers. Wouldn't such identifiers be pretty much useless? What I want from an identifier is be able to set up sessions towwards it, the same way I can now with a FQDN or IP address. If this isn't possible, what use are these identifiers? In this situation an identifierless solution would be better. And if there are ephemeral values that are used internally somewhere, we should probably avoid calling them "identifiers". In the good old days it would have been possible to presume that if two FQDN or IP address values are identical, they point to the same host. However, in these days of load balancers this is no longer true, although it's usually safe to make this assumption in applications because the different hosts would be providing the same service. In the design team # 1 we had some discussions on the FQDN <-> ID <-> locator relationship and I think we agreed that the ID should be tied to a single host, even if the FQDN is shared between more than one host. Obviously it must be possible to change identifiers. This means it must be possible to have more than one at the same time or operators will revolt. Another reason to have more than one ID at one point in time is for privacy reasons, this would be similar to RFC 3041. From owner-multi6@ops.ietf.org Wed Jun 16 13:13:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21995 for ; Wed, 16 Jun 2004 13:13:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Badxy-000674-IS for multi6-data@psg.com; Wed, 16 Jun 2004 17:12:50 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Badxp-00065x-Dc for multi6@ops.ietf.org; Wed, 16 Jun 2004 17:12:41 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5GHC7Lm084565 for ; Wed, 16 Jun 2004 19:12:08 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <5C8469AA-BFB8-11D8-B27A-00039388672E@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Multi6 From: Iljitsch van Beijnum Subject: draft remarks Date: Wed, 16 Jun 2004 10:12:35 -0700 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit After reading the following drafts in preparation for monday's meeting I noticed some stuff. draft-lear-multi6-things-to-think-about-03 - are there any questions about how site policy can be applied? (where "policy" has a big overlap with "traffic engineering" - I would like to see a new question: "Is it possible to implement the solution in middleboxes?" 3.4 I think the question about MPLS traffic engineering warrants a pointer to what exactly this is about, as this is a layer 2 thing which we can't assume everyone is familiar with 2.4.12 I think it's important to split between interaction of updated hosts in a multihomed site with unmodified correspondents, and operation of "legacy" hosts in multihomed sites. 2.4.13 "compatable"? 2.4.15 An IETF meeting isn't really an example of an ad-hoc network. Some people sitting together and creating a network on the fly without being able to request address space and such would be a better example. 2.4.19 Referrals don't work all that well in IPv4 either. I think a "must" is too strong here. For instance, if referrals fail after a rehoming event I would consider that acceptable. A separate effort to make referrals work well regardless of multi6 would be good, too. 2.4.20 Quotation marks gone astray. 4. You misspelled my name, and Patrik's too, I think. draft-nordmark-multi6-threats-02 1.1 I think the assumption that an attacker can do everything is dangerous, as this isn't a typical capability that an attacker would have. It's much more common that an attacker can just monitor, or monitor and inject but not block. Countermeasures that address these threats but not the one where an attacker can also block traffic could still be useful. 2- ULP I think that the definition of ULP clashes with other uses of the term, where it is used as "anything above the network layer" or "anything above the layer under discussion". The current definition is largely the same as "transport layer" if we ignore some more esoteric protocols that run on top of IP (such as ICMP) which are special cases with regard to multihoming anyway. 2 - address "unique identifier" can be read as "only identifier" but means "that uniquely identifies". 2 - identifier If not associated with an interface, then with what? (Host, of course... But what is a "host"?) 3.4 Slow down packets? Example please... Page 17: "signally"? BTW, it occurs to me that we can avoid some problems by imposing some restrictions on the FQDN <-> (identifier) <-> IP address/locator relationship(s). I.e., no longer allowing an FQDN to point to more than one host. Would this be a reasonable thing to do and/or useful? Re 3.4: I think it would be possible to mitigate many of the problems here by including a periodic state refresh and disallowing adding new locators when the original address which has been "validated" using return routability is no longer reachable. 4.3 can be addressed by reflecting the original address back so if the negotiation is corrupted by an attacker at least there is a way to trace this back part of the way. About 5: a good start would be to make a split between the state for incoming and outgoing sessions. Having to do work per session may not be so bad if there is a way to quickly sync up with the state that's already there for older sessions. Both hosts would then know they're still talking to the same correspondent. If this fails (maybe legitimate loss of state due to timeout) they can fall back to a full session initialization. Maybe a stupid idea, but would it be useful to have some mechanism to discover insecure links? A simple way to do this would be blocking (initial) multi6 packets on such links so initiating multihoming negotiations over such unsafe links which may lead to later redirection attacks becomes impossible. draft-huston-multi6-architectures-00 (Hm, was there a new version? I used the links from Brian's last announcement.) Page 8: "teh" Page 9: "sitines" 4.4 In theory there is a split between having site exit routers (actually many of the functions attributed to site exit routers here would be more naturally placed in middleboxes) determine which addresses are appropriate and then rewrite them, or have the hosts do this themselves. In reality, requiring all hosts AND all routers to be upgraded is a non-starter, so hosts must always be prepared to do this themselves, even if routers can do it too. 4.4 Comparing to NAT is not very appropriate as the addresses are written back before reaching the transport and/or application. 4.6 Note about tunneling: this is insecure as the implied relationship between inner and outer addresses can't be trusted. So this must be checked, but then the receiver knows what to expect so the actual inner values can be compressed away. I think we called this "aliasing" in the meeting. 4.6 Separate communications channel: "beware of the firewall" 5.1 ICMP triggers From owner-multi6@ops.ietf.org Wed Jun 16 13:43:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24179 for ; Wed, 16 Jun 2004 13:43:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaeOe-0008vf-Nd for multi6-data@psg.com; Wed, 16 Jun 2004 17:40:24 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaeOb-0008vA-P2 for multi6@ops.ietf.org; Wed, 16 Jun 2004 17:40:21 +0000 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5GHdbJ21839; Wed, 16 Jun 2004 10:39:38 -0700 (PDT) Message-ID: <40D085D5.9000801@isi.edu> Date: Wed, 16 Jun 2004 10:39:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: multi6@ops.ietf.org Subject: Re: identity persistence and comparison issues References: <40CDF8B3.3020101@isi.edu> In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4CE14137C7AC6D4DF50EC028" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4CE14137C7AC6D4DF50EC028 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 14 jun 2004, at 12:12, Joe Touch wrote: > >> a) are two IDs comparable within the same app over time? >> i.e., can an ID change? if so, can the old ID be used? > > >> b) can two IDs on different apps on the same node be compared? > > >> c) can two IDs on different nodes be compared? > > > During the meeting there was some talk about per-session identifiers. > Wouldn't such identifiers be pretty much useless? They're used in HIP, e.g. > What I want from an identifier is be able to set up sessions towwards > it, the same way I can now with a FQDN or IP address. If this isn't > possible, what use are these identifiers? In this situation an > identifierless solution would be better. And if there are ephemeral > values that are used internally somewhere, we should probably avoid > calling them "identifiers". The name of the endpoint (A) that you talk to isn't the same as the name used for forwarding (B), which may not be the same as any of the multiple endpoint addresses (C1...CN). The one I'm referring to is B. A might be a DNS name or current 'well known' IP address used to bootstrap the communication. > In the good old days it would have been possible to presume that if two > FQDN or IP address values are identical, they point to the same host. A FQDN has always been mappable to multiple IP addresses. If two IP addresses are identical, it is still the case that they either point to the same host or something that emulates one host. > However, in these days of load balancers this is no longer true, > although it's usually safe to make this assumption in applications > because the different hosts would be providing the same service. When load balancers break the 'same host or equivalent' they can 'break the Internet' (e.g., arbitrary protocols can break). > In the design team # 1 we had some discussions on the FQDN <-> ID <-> > locator relationship and I think we agreed that the ID should be tied to > a single host, even if the FQDN is shared between more than one host. A must be tied to a single host or something that emulates such, for the reasons above. > Obviously it must be possible to change identifiers. This means it must > be possible to have more than one at the same time or operators will > revolt. Another reason to have more than one ID at one point in time is > for privacy reasons, this would be similar to RFC 3041. Changing A is like renumbering now; a slow, out-of-band operation that requires resynchronization (e.g., of the DNS). Changing B is more of an opportunity than a liability... Joe --------------enig4CE14137C7AC6D4DF50EC028 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFA0IXeE5f5cImnZrsRAoH4AJ4sWYZJlFWC2rtNd85cj9+YT/JGGgCcDyov feKkgAZ+SgkZ5voD4988JOk= =pGgx -----END PGP SIGNATURE----- --------------enig4CE14137C7AC6D4DF50EC028-- From owner-multi6@ops.ietf.org Wed Jun 16 17:56:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20286 for ; Wed, 16 Jun 2004 17:56:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaiM9-00097N-TM for multi6-data@psg.com; Wed, 16 Jun 2004 21:54:05 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaiM7-00096h-TP for multi6@ops.ietf.org; Wed, 16 Jun 2004 21:54:04 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5GLrngB109482; Wed, 16 Jun 2004 21:53:49 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5GLrm8Y180988; Wed, 16 Jun 2004 23:53:48 +0200 Received: from zurich.ibm.com (sig-9-145-229-4.de.ibm.com [9.145.229.4]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA106496; Wed, 16 Jun 2004 23:53:41 +0200 Message-ID: <40D0C15F.8010804@zurich.ibm.com> Date: Wed, 16 Jun 2004 23:53:35 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Joe Touch CC: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: identity persistence and comparison issues References: <40CDF8B3.3020101@isi.edu> <40D085D5.9000801@isi.edu> In-Reply-To: <40D085D5.9000801@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe Touch wrote: > > > Iljitsch van Beijnum wrote: > >> On 14 jun 2004, at 12:12, Joe Touch wrote: >> >>> a) are two IDs comparable within the same app over time? >>> i.e., can an ID change? if so, can the old ID be used? >> >> >> >>> b) can two IDs on different apps on the same node be compared? >> >> >> >>> c) can two IDs on different nodes be compared? >> >> >> >> During the meeting there was some talk about per-session identifiers. >> Wouldn't such identifiers be pretty much useless? > > > They're used in HIP, e.g. > >> What I want from an identifier is be able to set up sessions towwards >> it, the same way I can now with a FQDN or IP address. If this isn't >> possible, what use are these identifiers? In this situation an >> identifierless solution would be better. And if there are ephemeral >> values that are used internally somewhere, we should probably avoid >> calling them "identifiers". > > > The name of the endpoint (A) that you talk to isn't the same as the name > used for forwarding (B), which may not be the same as any of the > multiple endpoint addresses (C1...CN). > > The one I'm referring to is B. A might be a DNS name or current 'well > known' IP address used to bootstrap the communication. > >> In the good old days it would have been possible to presume that if >> two FQDN or IP address values are identical, they point to the same host. > > > A FQDN has always been mappable to multiple IP addresses. If two IP > addresses are identical, it is still the case that they either point to > the same host or something that emulates one host. > >> However, in these days of load balancers this is no longer true, >> although it's usually safe to make this assumption in applications >> because the different hosts would be providing the same service. > > > When load balancers break the 'same host or equivalent' they can 'break > the Internet' (e.g., arbitrary protocols can break). > >> In the design team # 1 we had some discussions on the FQDN <-> ID <-> >> locator relationship and I think we agreed that the ID should be tied >> to a single host, even if the FQDN is shared between more than one host. > > > A must be tied to a single host or something that emulates such, for the > reasons above. > >> Obviously it must be possible to change identifiers. This means it >> must be possible to have more than one at the same time or operators >> will revolt. Another reason to have more than one ID at one point in >> time is for privacy reasons, this would be similar to RFC 3041. > > > Changing A is like renumbering now; a slow, out-of-band operation that > requires resynchronization (e.g., of the DNS). Changing B is more of an > opportunity than a liability... I think this is a very hard conversation to have in the abstract. I think it will be much easier to analyze these questions in terms of a specific proposal. So maybe we should note them as open, until our ongoing reduction of the solution set from many to few has been achieved. Brian From owner-multi6@ops.ietf.org Wed Jun 16 19:49:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02061 for ; Wed, 16 Jun 2004 19:49:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bak8R-000Lkb-JN for multi6-data@psg.com; Wed, 16 Jun 2004 23:48:03 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bak8P-000LkM-Qw for multi6@ops.ietf.org; Wed, 16 Jun 2004 23:48:02 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 08FDD39E86; Thu, 17 Jun 2004 01:48:01 +0200 (CEST) Received: from [163.117.252.237] (vpn-252-237.uc3m.es [163.117.252.237]) by smtp01.uc3m.es (Postfix) with ESMTP id E164039E46; Thu, 17 Jun 2004 01:47:59 +0200 (CEST) In-Reply-To: References: <40CDF8B3.3020101@isi.edu> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org, Joe Touch From: marcelo bagnulo braun Subject: Re: identity persistence and comparison issues Date: Thu, 17 Jun 2004 00:31:25 +0200 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Iljitsch, > During the meeting there was some talk about per-session identifiers. > Wouldn't such identifiers be pretty much useless? > > What I want from an identifier is be able to set up sessions towwards > it, the same way I can now with a FQDN or IP address. If this isn't > possible, what use are these identifiers? As i see it, there are two ends involved in a communication, the initiator of the communication and the responder. The responder of course has to have a stable id through which the initiator has to be capable to establish a communication with. I mean, the responder needs a stable id that it is known by the initiator in order to make initial contact. Now, the initiator may not need to have such a stable identifier, since the initiator does not receive communications. what the initiator needs is an identifier that is stable during the communication lifetime so, if the locator change, the identifier is maintained so it is the communication. So there are different requirements imposed to the intitator's identifier and the responder's identifier The responder's identifier has to be stable and known a priori so it can be used to make initial contact The intitiator's identifier has to be preserved during the communication lifetime and does not need to be known a priori (in the general case) Clearly and option would be to provide stable identifiers both to initiators and responders, but the issue here is that the security required by a stable identifier is likely to be more expensive than the security required by a ephemeral identifier. SO why would you provide additional (costly) features when they are not needed? > In this situation an identifierless solution would be better. And if > there are ephemeral values that are used internally somewhere, we > should probably avoid calling them "identifiers". Well, i usually make the difference between ephemeral ids vs. stable ids. ephemeral ids are valid during a communication lifetime stable ids are more long lived and can be used for initial contact regards, marcelo > > In the good old days it would have been possible to presume that if > two FQDN or IP address values are identical, they point to the same > host. However, in these days of load balancers this is no longer true, > although it's usually safe to make this assumption in applications > because the different hosts would be providing the same service. > > In the design team # 1 we had some discussions on the FQDN <-> ID <-> > locator relationship and I think we agreed that the ID should be tied > to a single host, even if the FQDN is shared between more than one > host. > > Obviously it must be possible to change identifiers. This means it > must be possible to have more than one at the same time or operators > will revolt. Another reason to have more than one ID at one point in > time is for privacy reasons, this would be similar to RFC 3041. > > From owner-multi6@ops.ietf.org Thu Jun 17 15:51:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08908 for ; Thu, 17 Jun 2004 15:51:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb2sS-000LRX-Gx for multi6-data@psg.com; Thu, 17 Jun 2004 19:48:48 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb2sR-000LRE-JA for multi6@ops.ietf.org; Thu, 17 Jun 2004 19:48:47 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5HJmdJ6022593; Thu, 17 Jun 2004 12:48:40 -0700 (PDT) Received: from jurassic (jurassic.SFBay.Sun.COM [129.146.17.57]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5HJmaQ10013; Thu, 17 Jun 2004 21:48:36 +0200 (MEST) Date: Thu, 17 Jun 2004 12:46:58 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-nordmark-multi6-threats-01.txt To: Kurt Erik Lindqvist Cc: Erik Nordmark , Multi6 List , marcelo bagnulo braun In-Reply-To: "Your message with ID" <982A3C86-BD41-11D8-B677-000A95928574@kurtis.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > But doesn't one-way authentication without mutual authentication imply > a different trust model? I.e one end chooses to not to authenticate > while the other end does authenticate. Yes, but the point was that the document already talks about this by explicitly separating the client side from the server side considerations. Erik From owner-multi6@ops.ietf.org Thu Jun 17 15:51:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08927 for ; Thu, 17 Jun 2004 15:51:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb2sW-000LSH-7P for multi6-data@psg.com; Thu, 17 Jun 2004 19:48:52 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb2sV-000LRv-Bl for multi6@ops.ietf.org; Thu, 17 Jun 2004 19:48:51 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i5HJme0R025945; Thu, 17 Jun 2004 12:48:42 -0700 (PDT) Received: from jurassic (jurassic.SFBay.Sun.COM [129.146.17.57]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5HJmYQ10011; Thu, 17 Jun 2004 21:48:35 +0200 (MEST) Date: Thu, 17 Jun 2004 12:46:58 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-nordmark-multi6-threats-01.txt To: Kurt Erik Lindqvist Cc: Erik Nordmark , Multi6 List , marcelo bagnulo braun In-Reply-To: "Your message with ID" <982A3C86-BD41-11D8-B677-000A95928574@kurtis.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > But doesn't one-way authentication without mutual authentication imply > a different trust model? I.e one end chooses to not to authenticate > while the other end does authenticate. Yes, but the point was that the document already talks about this by explicitly separating the client side from the server side considerations. Erik From owner-multi6@ops.ietf.org Fri Jun 18 10:15:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25405 for ; Fri, 18 Jun 2004 10:15:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbK75-0002vU-Jp for multi6-data@psg.com; Fri, 18 Jun 2004 14:13:03 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbK74-0002vE-OK for multi6@ops.ietf.org; Fri, 18 Jun 2004 14:13:02 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 18 Jun 2004 07:14:28 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i5IECxiJ002749; Fri, 18 Jun 2004 07:13:00 -0700 (PDT) Received: from [10.61.124.97] (ams-clip-equant-dhcp-96.cisco.com [10.61.124.97]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA24076; Fri, 18 Jun 2004 07:12:56 -0700 (PDT) Message-ID: <40D2F867.3050107@cisco.com> Date: Fri, 18 Jun 2004 16:12:55 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 Subject: Re: draft remarks References: <5C8469AA-BFB8-11D8-B27A-00039388672E@muada.com> In-Reply-To: <5C8469AA-BFB8-11D8-B27A-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi! I've reworked the document based on Geoff's comments. Questions are the same, but just in different order. Iljitsch van Beijnum wrote: > - are there any questions about how site policy can be applied? (where > "policy" has a big overlap with "traffic engineering" You mean like access-lists? There are specific questions regarding TE. 4.2 Does your solution impact existing traffic engineering methods, such as MPLS-TE? Traffic engineering allows for source-based traffic aggregation to a particular destination. How will your mechanism interact with such existing methods? > - I would like to see a new question: "Is it possible to implement the > solution in middleboxes? 3.10 Middlbox interactions What are the implications for firewalls? What are the interactions with NAT? What are the interactions with web caches? What complications are introduced with your solution? For instance, are there implication for ingress filters? If so, what are they? " > 3.4 I think the question about MPLS traffic engineering warrants a > pointer to what exactly this is about, as this is a layer 2 thing which > we can't assume everyone is familiar with Got a suggestion? > 2.4.12 I think it's important to split between interaction of updated > hosts in a multihomed site with unmodified correspondents, and operation > of "legacy" hosts in multihomed sites. This is where 2.4.15 was going. Is that not sufficient? How will your solution interact with > 2.4.13 "compatable"? > 2.4.15 An IETF meeting isn't really an example of an ad-hoc network. > Some people sitting together and creating a network on the fly without > being able to request address space and such would be a better example. You mean like our just concluded interim meeting? ;-) You're right. And that's a case to point out. What I really meant were short-lived network associations. We could probably use iPass or T-Mobile as the case in point I actually had in my head. > 2.4.19 Referrals don't work all that well in IPv4 either. I think a > "must" is too strong here. For instance, if referrals fail after a > rehoming event I would consider that acceptable. A separate effort to > make referrals work well regardless of multi6 would be good, too. This is an area that I think needs just a bit more work, in any event. First of all, this is not a requirements document, and if you read it as such, then I went afoul of my own intent. But beyond that, many people *are* concerned about what the binding between location and address means. For instance, will that binding vary based on who's asking? Will the same binding work if one of the two correspondents move? FTP was (I thought) the trivial case of this, because time is not generally a factor. Of course, firewalls are. > 2.4.20 Quotation marks gone astray. doh. > 4. You misspelled my name, and Patrik's too, I think. doh * 2. My apologies to you both. Eliot From owner-multi6@ops.ietf.org Fri Jun 18 16:58:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21993 for ; Fri, 18 Jun 2004 16:58:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbQPT-000LqV-G5 for multi6-data@psg.com; Fri, 18 Jun 2004 20:56:27 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbQPR-000LqA-Sc for multi6@ops.ietf.org; Fri, 18 Jun 2004 20:56:26 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5IKtBLm036877; Fri, 18 Jun 2004 22:55:13 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <40D2F867.3050107@cisco.com> References: <5C8469AA-BFB8-11D8-B27A-00039388672E@muada.com> <40D2F867.3050107@cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: draft remarks Date: Fri, 18 Jun 2004 22:55:45 +0200 To: Eliot Lear X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 18-jun-04, at 16:12, Eliot Lear wrote: >> - are there any questions about how site policy can be applied? >> (where "policy" has a big overlap with "traffic engineering" > You mean like access-lists? There are specific questions regarding TE. No, ACLs or traffic engineering in general are not not what I mean. Different people mean different things when they talk about policy. The subset that I'm interested in is the situation where a network is multihomed, and it wants/needs to reach certain destinations over one particular link under normal circumstances. In a situation where decisions by hosts determine the link used for incoming and/or outgoing packets, there is no obvious way to push such a policy out to all hosts within the site. >> - I would like to see a new question: "Is it possible to implement >> the solution in middleboxes? > 3.10 Middlbox interactions > What are the implications for firewalls? What are the interactions > with NAT? What are the interactions with web caches? What > complications are introduced with your solution? For instance, are > there implication for ingress filters? If so, what are they? This question assumes that the solution is implemented somewhere (such as in hosts) and asks how otherwise unrelated middleboxes are going to function in the presence of multihoming. What I'm getting at is that the situation that the solution is implemented inside a middlebox or site exit router such that unodified hosts can benefit from being multihomed. That's a different issue. >> 3.4 I think the question about MPLS traffic engineering warrants a >> pointer to what exactly this is about, as this is a layer 2 thing >> which we can't assume everyone is familiar with > Got a suggestion? No. Quite the reverse: I'd like to read such a document in order to see what all the fuss is about. >> 2.4.12 I think it's important to split between interaction of updated >> hosts in a multihomed site with unmodified correspondents, and >> operation of "legacy" hosts in multihomed sites. > This is where 2.4.15 was going. Is that not sufficient? At first glance this seems to be about deployment scenarios, this question isn't very clear. >> 2.4.15 An IETF meeting isn't really an example of an ad-hoc network. >> Some people sitting together and creating a network on the fly >> without being able to request address space and such would be a >> better example. > You mean like our just concluded interim meeting? ;-) Right. I was also thinking about networks without any connectivity at all, but I just realized those aren't going to be multihomed so they are of no interest to us. :-) > We could probably use iPass or T-Mobile as the case in point I > actually had in my head. I've never heard of iPass and T-Mobile is the outfit that bills me for using my cellphone, so I'm not sure if those names are helpful... >> 2.4.19 Referrals don't work all that well in IPv4 either. I think a >> "must" is too strong here. For instance, if referrals fail after a >> rehoming event I would consider that acceptable. A separate effort to >> make referrals work well regardless of multi6 would be good, too. > This is an area that I think needs just a bit more work, in any event. > First of all, this is not a requirements document, and if you read it > as such, then I went afoul of my own intent. Yes, this alone is sufficient reason to remove the "must". However, I was overlooking that fact and arguing that even in a requirements document (which this isn't and we don't have) this requirement would probably be too strong. > But beyond that, many people *are* concerned about what the binding > between location and address means. For instance, will that binding > vary based on who's asking? Will the same binding work if one of the > two correspondents move? FTP was (I thought) the trivial case of > this, because time is not generally a factor. Of course, firewalls > are. FTP is an interesting case because it supports a controller X directing Y to send a file to Z and Z to receive it from Y. Now consider the situation where X communicates with addresses Y1 and Z1, but Y and Z can only reach each other at Y2 and Z2. I guess all of this is solvable by introducing an identifier and a mapping service, or going through a reverse, forward DNS lookup cycle (if the FQDN - host relationsip is 1-on-1), but I think this is a challenging problem in its own right rather than just a footnote in the history of multihoming. Iljitsch From owner-multi6@ops.ietf.org Fri Jun 18 17:08:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22428 for ; Fri, 18 Jun 2004 17:08:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbQZa-000NE2-Bi for multi6-data@psg.com; Fri, 18 Jun 2004 21:06:54 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbQZY-000NDU-Q0 for multi6@ops.ietf.org; Fri, 18 Jun 2004 21:06:53 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i5IL6pN23483; Sat, 19 Jun 2004 00:06:51 +0300 Date: Sat, 19 Jun 2004 00:06:51 +0300 (EEST) From: Pekka Savola To: multi6@ops.ietf.org cc: fred@cisco.com, , Subject: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk FYI -- IMHO, making sure that renumbering a network is as simple as it can be is a subject which is very much related to multi6 designs.. and IMHO an operational requirement if we wish to deploy a model where we might envision populating hosts on a site with multiple addresses. So, review of the v6ops document describing a renumbering procedure would be very much appreciated. Please send the comments on v6ops list! ---------- Forwarded message ---------- Date: Sat, 19 Jun 2004 00:00:55 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Cc: fred@cisco.com, rdroms@cisco.com, lear@cisco.com Subject: WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt Hi all, (co-chair hat on) This is the WG Last Call for comments on sending draft-ietf-v6ops-renumbering-procedure-00.txt, "Procedures for Renumbering an IPv6 Network without a Flag Day" to the IESG for consideration as Informational: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering-procedure-00.txt Please review the document carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. Please note that this was originally thought to go for BCP instead of Informational, but the procedure might not yet warrant the BCP "seal of approval", so informational was tentatively chosen instead. If you have preferences about this, please indicate them during the WGLC as well. The last call will end in about 2 weeks, on 4th July. Thanks! From owner-multi6@ops.ietf.org Sat Jun 19 14:54:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03270 for ; Sat, 19 Jun 2004 14:54:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bbkw8-000K9x-A7 for multi6-data@psg.com; Sat, 19 Jun 2004 18:51:32 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bbkw7-000K9W-2E for multi6@ops.ietf.org; Sat, 19 Jun 2004 18:51:31 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5JIpS627186; Sat, 19 Jun 2004 21:51:28 +0300 (EET DST) X-Scanned: Sat, 19 Jun 2004 21:51:01 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i5JIp1Wt014151; Sat, 19 Jun 2004 21:51:01 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00o6PjgW; Sat, 19 Jun 2004 21:51:00 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5JIZjH22720; Sat, 19 Jun 2004 21:35:45 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 19 Jun 2004 21:35:34 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 19 Jun 2004 21:35:32 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft remarks Date: Sat, 19 Jun 2004 21:35:32 +0300 Message-ID: Thread-Topic: draft remarks Thread-Index: AcRVPv1r8FM8M9QgSwa9WYgij6kkcAAYJOXg From: To: , Cc: X-OriginalArrivalTime: 19 Jun 2004 18:35:32.0608 (UTC) FILETIME=[341CF800:01C4562C] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Elliot, > Iljitsch van Beijnum wrote: > > - are there any questions about how site policy can be applied? = (where=20 > > "policy" has a big overlap with "traffic engineering" >=20 > You mean like access-lists? There are specific questions=20 > regarding TE. >=20 > 4.2 Does your solution impact existing traffic engineering methods, > such as MPLS-TE? >=20 > Traffic engineering allows for source-based traffic aggregation to = a > particular destination. How will your mechanism interact with = such > existing methods? I'd hesitate explicitly calling out MPLS-TE - there are otherways to 'manage' a network. I'd make it more general: 4.2 Does your solution impact existing network management tools and = techniques? =20 Traffic engineering allows for source-based traffic aggregation to = a particular destination. How will your mechanism interact with such existing methods? How will your mechanisms interact with existing=20 network management tools? > > - I would like to see a new question: "Is it possible to=20 > implement the=20 > > solution in middleboxes? >=20 > 3.10 Middlbox interactions >=20 > What are the implications for firewalls? What are the = interactions > with NAT? What are the interactions with web caches? What > complications are introduced with your solution? For instance, = are > there implication for ingress filters? If so, what are they? add: What are the implications for proxies? =20 John From owner-multi6@ops.ietf.org Sun Jun 20 00:03:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27583 for ; Sun, 20 Jun 2004 00:03:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbtV3-000Lfq-4B for multi6-data@psg.com; Sun, 20 Jun 2004 04:00:09 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbtV2-000Lfa-3v for multi6@ops.ietf.org; Sun, 20 Jun 2004 04:00:08 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 72CF327 for ; Sun, 20 Jun 2004 00:00:07 -0400 (EDT) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 20 Jun 2004 00:00:07 -0400 Message-Id: <20040620040007.72CF327@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.29% | 4 | 45.17% | 80836 | kurtis@kurtis.pp.se 25.00% | 7 | 14.09% | 25220 | iljitsch@muada.com 21.43% | 6 | 10.13% | 18131 | brc@zurich.ibm.com 7.14% | 2 | 13.33% | 23853 | marcelo@it.uc3m.es 7.14% | 2 | 5.00% | 8955 | touch@isi.edu 3.57% | 1 | 2.80% | 5005 | lear@cisco.com 3.57% | 1 | 2.33% | 4176 | john.loughney@nokia.com 3.57% | 1 | 1.69% | 3028 | pekkas@netcore.fi 3.57% | 1 | 1.62% | 2895 | gih@telstra.net 3.57% | 1 | 1.39% | 2493 | sra@hactrn.net 3.57% | 1 | 1.26% | 2256 | erik.nordmark@sun.com 3.57% | 1 | 1.17% | 2095 | margaret@thingmagic.com --------+------+--------+----------+------------------------ 100.00% | 28 |100.00% | 178943 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Sun Jun 20 10:58:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10292 for ; Sun, 20 Jun 2004 10:58:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bc3jd-000OH7-4h for multi6-data@psg.com; Sun, 20 Jun 2004 14:55:53 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bc3jb-000OGa-NZ for multi6@ops.ietf.org; Sun, 20 Jun 2004 14:55:52 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5KEtB0A077188; Sun, 20 Jun 2004 16:55:13 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: draft remarks Date: Sun, 20 Jun 2004 16:55:46 +0200 To: X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 19-jun-04, at 20:35, wrote: > I'd hesitate explicitly calling out MPLS-TE - there are otherways to > 'manage' a network. I'd make it more general: > 4.2 Does your solution impact existing network management tools and > techniques? [...] > add: > What are the implications for proxies? Hm, this way the document is quickly becoming "list the way your solution interacts with RFCs 1 - 3800". The value of this document is that it reminds authors of issues that may be pertinent to their solution. In order to do this, it's important to offer a rationale for including a question. I see no reason why multi-address multihoming would impact network management or proxies. If you do, it would be good to say why, so authors can determine whether your concerns are warrented. From owner-multi6@ops.ietf.org Sun Jun 20 17:13:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29741 for ; Sun, 20 Jun 2004 17:13:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bc9ak-0006zk-JS for multi6-data@psg.com; Sun, 20 Jun 2004 21:11:06 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bc9ai-0006zC-Id; Sun, 20 Jun 2004 21:11:04 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5KLAJ0A083353; Sun, 20 Jun 2004 23:10:19 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Ralph Droms , v6ops@ops.ietf.org, Eliot Lear , Multi6 , Fred Baker From: Iljitsch van Beijnum Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Date: Sun, 20 Jun 2004 23:10:54 +0200 To: Pekka Savola X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 18-jun-04, at 23:06, Pekka Savola wrote: > IMHO, making sure that renumbering a network is as simple as it can be > is a subject which is very much related to multi6 designs.. and IMHO > an operational requirement if we wish to deploy a model where we might > envision populating hosts on a site with multiple addresses. > So, review of the v6ops document describing a renumbering procedure > would be very much appreciated. Please send the comments on v6ops > list! Ok, first comment is relevant to multi6: Having two prefixes at the same time lands you squarely inside the domain of draft-huitema-... The draft now assumes that having both old and new addresses works, and this isn't an assumption you can just make. In the case of changing addresses where both address ranges come from the same ISP this could be the case, but I don't see how this would be a regularly occurring event (after the 6bone has been shut down). In the case that both prefixes come from different ISPs, the network essentially becomes multihomed periodically, so it suffers all the ingress filtering trouble that we've been discussing in multi6. The draft only talks about ingress filtering with regard to security, which IMNSHO is stupid because there are no attacks that are possible with spoofed addresses that aren't possible with unspoofed addresses. It's just that tracking the attacks down takes longer. The real issue is that you MUST deliver packets to the ISP that matches the source address or you have no connecitivity. There are three ways this can happen: 1. disable ingress filtering for one ISP and route everything over that ISP 2. use policy routing or some other source address based routing to route packets to the ISP matching the source address 3. have a flag day Talking about flag days: I'm missing a discussion on making use of the possibility of deprecating a prefix when stateless autoconfiguration is used. This mechanism makes it possible to move all new (outgoing) sessions to a new prefix in a couple of minutes. All in all I think this draft is suffering from lack of ambition. Either provide some real guidance rather than a bunch of truisms or drop the whole thing. As I'm feeling generous today here's a partial list of suggestions in the area of renumbering that people usually only get to read after paying $40 or so: - register the new addresses for authorative nameservers with all pertinent registries as soon as the nameservers are reachable over the new addresses - there are two ways to change server addresses fairly painlessly: lower the DNS TTLs and do it at once, or run two addresses side by side for a while. The latter is usually more work but can be done without any interruption at all - log (attempted) use of the old addresses to see whether everything has switched - turn off the old addresses for a while to flush out the last users, then turn them back on again so those last users get to change over without too much network interruption - when the old addresses are removed, do traceroutes in various places to see if they're really gone From owner-multi6@ops.ietf.org Sun Jun 20 22:27:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15939 for ; Sun, 20 Jun 2004 22:27:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcEW3-000Dmt-1h for multi6-data@psg.com; Mon, 21 Jun 2004 02:26:35 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BcEW1-000DmZ-U7 for multi6@ops.ietf.org; Mon, 21 Jun 2004 02:26:34 +0000 Received: (qmail 34656 invoked from network); 21 Jun 2004 02:24:59 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 21 Jun 2004 02:24:59 -0000 Message-ID: <40D6488A.7010000@necom830.hpcl.titech.ac.jp> Date: Mon, 21 Jun 2004 11:31:38 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 Subject: Re: WG adoption of draft-nordmark-multi6-threats-01.txt References: <40CF2F1E.9010904@zurich.ibm.com> In-Reply-To: <40CF2F1E.9010904@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > Multi6 people, > > At yesterday's meeting there was strong consensus to adopt > draft-nordmark-multi6-threats-01.txt > as a WG draft. > > If you do not agree with this please say so within a week. I do not agree. With no meeting minutes, I don't think any reasoning necessary. Masataka Ohta From owner-multi6@ops.ietf.org Sun Jun 20 22:27:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15957 for ; Sun, 20 Jun 2004 22:27:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcEV8-000DkJ-08 for multi6-data@psg.com; Mon, 21 Jun 2004 02:25:38 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BcEV6-000Dk1-HH for multi6@ops.ietf.org; Mon, 21 Jun 2004 02:25:37 +0000 Received: (qmail 34643 invoked from network); 21 Jun 2004 02:24:01 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 21 Jun 2004 02:24:01 -0000 Message-ID: <40D64850.7020703@necom830.hpcl.titech.ac.jp> Date: Mon, 21 Jun 2004 11:30:40 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 Subject: Re: WG adoption of draft-lear-multi6-things-to-think-about-03.txt References: <40CF2EE2.9030904@zurich.ibm.com> In-Reply-To: <40CF2EE2.9030904@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > Multi6 people, > > At yesterday's meeting there was strong consensus to adopt > draft-lear-multi6-things-to-think-about-03.txt > as a WG draft. > > If you do not agree with this please say so within a week. I do not agree. With no meeting minutes, I don't think any reasoning necessary. Masataka Ohta From owner-multi6@ops.ietf.org Mon Jun 21 03:45:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18162 for ; Mon, 21 Jun 2004 03:45:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcJSJ-000IB9-P9 for multi6-data@psg.com; Mon, 21 Jun 2004 07:43:03 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcJSI-000IAp-7q for multi6@ops.ietf.org; Mon, 21 Jun 2004 07:43:02 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 28F0446E675; Mon, 21 Jun 2004 09:43:00 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <9BA66E3C-C356-11D8-BBC1-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List , marcelo bagnulo braun From: Kurt Erik Lindqvist Subject: Re: draft-nordmark-multi6-threats-01.txt Date: Mon, 21 Jun 2004 09:42:55 +0200 To: Erik Nordmark X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-17, at 21.46, Erik Nordmark wrote: >> But doesn't one-way authentication without mutual authentication imply >> a different trust model? I.e one end chooses to not to authenticate >> while the other end does authenticate. > > Yes, but the point was that the document already talks about this > by explicitly separating the client side from the server side > considerations. Yes. But I meant that there is a different trust model if one of the sides (where both have the ability to authenticate) decides not to authenticate. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNaRgqarNKXTPFCVEQILeQCg7f8B6ScmegfRfdtVQ4Px448FPZEAnAoY 6fikfXOMx7pI2JBEk+8NETER =ZzZm -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Jun 21 03:46:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18180 for ; Mon, 21 Jun 2004 03:46:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcJTv-000IIr-OB for multi6-data@psg.com; Mon, 21 Jun 2004 07:44:43 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcJTu-000IIa-Su for multi6@ops.ietf.org; Mon, 21 Jun 2004 07:44:43 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 0E40646E68F; Mon, 21 Jun 2004 09:44:41 +0200 (CEST) In-Reply-To: <40D6488A.7010000@necom830.hpcl.titech.ac.jp> References: <40CF2F1E.9010904@zurich.ibm.com> <40D6488A.7010000@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 , Brian E Carpenter From: Kurt Erik Lindqvist Subject: Re: WG adoption of draft-nordmark-multi6-threats-01.txt Date: Mon, 21 Jun 2004 09:44:37 +0200 To: Masataka Ohta X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-21, at 04.31, Masataka Ohta wrote: > With no meeting minutes, I don't think any reasoning necessary. While waiting for official minutes, the Jabber logs can be found here http://www.xmpp.org/ietf-logs/multi6@ietf.xmpp.org/2004-06-14.html. And the drafts are the drafts. You either agree with them or you don't. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNaR56arNKXTPFCVEQL5kQCeJ7HQmIN0LUbyMiHK4I3rGpO360cAn1vS neEjEXkZ7TmmNE2qf7+eyjy3 =qi75 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Jun 21 03:50:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18795 for ; Mon, 21 Jun 2004 03:50:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcJYU-000IrZ-0E for multi6-data@psg.com; Mon, 21 Jun 2004 07:49:26 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcJYS-000Ir7-S2; Mon, 21 Jun 2004 07:49:24 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 21 Jun 2004 00:52:38 -0700 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5L7nKlq012283; Mon, 21 Jun 2004 00:49:21 -0700 (PDT) Received: from [10.61.124.162] (ams-clip-equant-dhcp-161.cisco.com [10.61.124.162]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id AAA19936; Mon, 21 Jun 2004 00:49:15 -0700 (PDT) Message-ID: <40D692F9.3000603@cisco.com> Date: Mon, 21 Jun 2004 09:49:13 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Pekka Savola , Ralph Droms , v6ops@ops.ietf.org, Multi6 , Fred Baker Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) References: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> In-Reply-To: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > Ok, first comment is relevant to multi6: > > Having two prefixes at the same time lands you squarely inside the > domain of draft-huitema-... The draft now assumes that having both old > and new addresses works, and this isn't an assumption you can just make. No, we assume that the network is in a nominal state prior to renumbering. The issue you raise below would indicate that perhaps this *isn't* the case. In which case your problems are bigger than renumbering. > In the case of changing addresses where both address ranges come from > the same ISP this could be the case, but I don't see how this would be a > regularly occurring event (after the 6bone has been shut down). In the > case that both prefixes come from different ISPs, the network > essentially becomes multihomed periodically, so it suffers all the > ingress filtering trouble that we've been discussing in multi6. We make note of the fact that there is a linkage between the upstream ISP and the network. What perhaps we should state is that upstreams may need to know about each other from anti-spoofing mechanism. > The > draft only talks about ingress filtering with regard to security, which > IMNSHO is stupid because there are no attacks that are possible with > spoofed addresses that aren't possible with unspoofed addresses. One of us has missed the point. Firewalls today filter packets based on destination address. While I would agree that filtering on a source FROM the Internet would be foolish, different hosts on the perimeter may require different levels of protection. Regardless, those rules exist today inside firewalls and would need to be changed, and that's what we're saying. > It's > just that tracking the attacks down takes longer. The real issue is that > you MUST deliver packets to the ISP that matches the source address or > you have no connecitivity. There are three ways this can happen: > > 1. disable ingress filtering for one ISP and route everything over that ISP > 2. use policy routing or some other source address based routing to > route packets to the ISP matching the source address > 3. have a flag day This configuration either exists prior to the renumbering events or it doesn't. If it does it would need to be modified to match the new addresses. The renumbering document does not attempt to solve the multi6 problem. > > Talking about flag days: I'm missing a discussion on making use of the > possibility of deprecating a prefix when stateless autoconfiguration is > used. This mechanism makes it possible to move all new (outgoing) > sessions to a new prefix in a couple of minutes. This is a best case scenario that assumes all the appropriate linkages for reverse dns lookups that almost assuredly don't exist, not to mention the TTLs that are present. If what you wrote above was the general case I wouldn't have cared to get involved in such a document. > > All in all I think this draft is suffering from lack of ambition. Either > provide some real guidance rather than a bunch of truisms or drop the > whole thing. This draft's ambition is to document the process, and perhaps point out a few areas for improvement in the standards/development front. I personally think it also shows that the problem is really no less complex than IPv4, and if we add the MULTI6 fun, we could make it moreso. Want to make it easier? Great. I'm all ears. Perhaps that will be the killer app for IPv6, but I doubt it. My motivation was really to make incremental progress on eliminating the need for site-local and natting. Eliot From owner-multi6@ops.ietf.org Mon Jun 21 03:56:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19167 for ; Mon, 21 Jun 2004 03:56:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcJeh-000JvK-Ov for multi6-data@psg.com; Mon, 21 Jun 2004 07:55:51 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcJeg-000Juo-Nv for multi6@ops.ietf.org; Mon, 21 Jun 2004 07:55:50 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id C4B7346E784; Mon, 21 Jun 2004 09:55:48 +0200 (CEST) In-Reply-To: References: <5C8469AA-BFB8-11D8-B27A-00039388672E@muada.com> <40D2F867.3050107@cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <64B7DEE8-C358-11D8-BBC1-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 , Eliot Lear From: Kurt Erik Lindqvist Subject: Re: draft remarks Date: Mon, 21 Jun 2004 09:55:42 +0200 To: Iljitsch van Beijnum X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-18, at 22.55, Iljitsch van Beijnum wrote: > >>> 2.4.19 Referrals don't work all that well in IPv4 either. I think a >>> "must" is too strong here. For instance, if referrals fail after a >>> rehoming event I would consider that acceptable. A separate effort >>> to make referrals work well regardless of multi6 would be good, too. > >> This is an area that I think needs just a bit more work, in any >> event. First of all, this is not a requirements document, and if you >> read it as such, then I went afoul of my own intent. > > Yes, this alone is sufficient reason to remove the "must". However, I > was overlooking that fact and arguing that even in a requirements > document (which this isn't and we don't have) this requirement would > probably be too strong. While I agree that a must would imply that the document have some form or requirements status, referrals are of such a strong demand from applications that I think this needs to be addressed one way or the other. But at the interim meeting we already said that we would try and cover applications requirements in some way. So I agree with Iljitsch but I do think that the question should be in the document. Perhaps we could also come up with some more sub-questions for this point for helping describing exactly how referrals would work. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNaUg6arNKXTPFCVEQK6cgCfcYp+oWNUb9Q8nDGXGDCDsj/IzuIAn2rQ 0GTh3qPlfiYxxpyhBlS9/DZE =sLiW -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Jun 21 04:07:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19885 for ; Mon, 21 Jun 2004 04:07:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcJoz-000LOq-U4 for multi6-data@psg.com; Mon, 21 Jun 2004 08:06:29 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcJoz-000LOY-0h for multi6@ops.ietf.org; Mon, 21 Jun 2004 08:06:29 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Jun 2004 01:07:57 +0000 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i5L84rgI006794; Mon, 21 Jun 2004 01:04:53 -0700 (PDT) Received: from [10.61.124.162] (ams-clip-equant-dhcp-161.cisco.com [10.61.124.162]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id BAA26824; Mon, 21 Jun 2004 01:04:50 -0700 (PDT) Message-ID: <40D696A0.9070208@cisco.com> Date: Mon, 21 Jun 2004 10:04:48 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Iljitsch van Beijnum , Multi6 Subject: Re: draft remarks References: <5C8469AA-BFB8-11D8-B27A-00039388672E@muada.com> <40D2F867.3050107@cisco.com> <64B7DEE8-C358-11D8-BBC1-000A95928574@kurtis.pp.se> In-Reply-To: <64B7DEE8-C358-11D8-BBC1-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt Erik Lindqvist wrote: > While I agree that a must would imply that the document have some form > or requirements status, referrals are of such a strong demand from > applications that I think this needs to be addressed one way or the > other. But at the interim meeting we already said that we would try and > cover applications requirements in some way. So I agree with Iljitsch > but I do think that the question should be in the document. Perhaps we > could also come up with some more sub-questions for this point for > helping describing exactly how referrals would work. Right. What I was aiming for was something along these lines: Referrals How will your solution handle referrals, such as those within FTP or various conferencing or other peer to peer systems? Referrals exist within various other protocols, such as so-called "peer to peer" applications. Note that referrals might suffer three types of failure: firewall and NAT - just as FTP active mode experiences today with relatively simple firewalls? time-based - is there something ephemeral about the nature of the solution that might cause a referral (such as a URL) to fail over time, more so than what we have today? location-based - if the binding varies based on where the parties are in the network, if one moves will they no longer be able to find one another? And the following: What application/API changes are needed? Will old code just work with the new mechanism? For instance, what about code that uses gethostbyname()? Will getaddrinfo() need to change? What about other API calls? There are several possible approaches. For instance, a multihoming service could attempt to require no changes to the API, in which case it is possible that IP addresses might become opaque blobs that work with the API, but might break operational assumptions at the application layers. Consider the case of a web server that wants to log IP addresses. How will it accomplish this task? One useful exercise would be to provide code fragments that demonstrate any API changes. Eliot From owner-multi6@ops.ietf.org Mon Jun 21 04:08:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19964 for ; Mon, 21 Jun 2004 04:08:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcJqB-000LYk-Pa for multi6-data@psg.com; Mon, 21 Jun 2004 08:07:43 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcJqA-000LYQ-TD for multi6@ops.ietf.org; Mon, 21 Jun 2004 08:07:42 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 21 Jun 2004 01:09:54 -0700 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i5L87dZr018266; Mon, 21 Jun 2004 01:07:39 -0700 (PDT) Received: from [10.61.124.162] (ams-clip-equant-dhcp-161.cisco.com [10.61.124.162]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id BAA28239; Mon, 21 Jun 2004 01:07:36 -0700 (PDT) Message-ID: <40D69747.8000501@cisco.com> Date: Mon, 21 Jun 2004 10:07:35 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: john.loughney@nokia.com, Multi6 Subject: Re: draft remarks References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 19-jun-04, at 20:35, wrote: > >> I'd hesitate explicitly calling out MPLS-TE - there are otherways to >> 'manage' a network. I'd make it more general: > > >> 4.2 Does your solution impact existing network management tools and >> techniques? > > > [...] > >> add: >> What are the implications for proxies? > > > Hm, this way the document is quickly becoming "list the way your > solution interacts with RFCs 1 - 3800". Right. I agree. We can't predict all pitfalls, but for instance, to tie into another message from Iljitsch, perhaps we should point out that if a mechanism uses some nifty hack on addressing and someone is doing MPLS-TE based on source address, you could have a problem. On the other hand, I'm also perfectly happy removing the question in its entirety. Eliot From owner-multi6@ops.ietf.org Mon Jun 21 04:17:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20441 for ; Mon, 21 Jun 2004 04:17:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcJz1-000Mbt-7Z for multi6-data@psg.com; Mon, 21 Jun 2004 08:16:51 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcJyz-000Mb9-1f; Mon, 21 Jun 2004 08:16:49 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i5L8GmnE022295; Mon, 21 Jun 2004 09:16:48 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA20094; Mon, 21 Jun 2004 09:16:46 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i5L8GkA24667; Mon, 21 Jun 2004 09:16:46 +0100 Date: Mon, 21 Jun 2004 09:16:46 +0100 From: Tim Chown To: v6ops@ops.ietf.org, Multi6 Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Message-ID: <20040621081646.GJ23590@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org, Multi6 References: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> <40D692F9.3000603@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D692F9.3000603@cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, Jun 21, 2004 at 09:49:13AM +0200, Eliot Lear wrote: > > One of us has missed the point. Firewalls today filter packets based on > destination address. While I would agree that filtering on a source > FROM the Internet would be foolish, different hosts on the perimeter may > require different levels of protection. Regardless, those rules exist > today inside firewalls and would need to be changed, and that's what > we're saying. It's probablymuch more common than you'd fear that sites use source address based filtering in firewalls. And of course that's the snag that the firewall rules need updating (or at least reloading/resolving) on remote site firewalls not just on the renumbering site. There's also plenty of examples of source IP based access controls in other places, e.g. in the transport layer in TCP wrapper configuration files, or in the application layer with, e.g., IP-based access control to web resources (publisher material being a common one in academic circles - a big university is granted access by it's whole Class B site block). > Want to make it easier? Great. I'm all ears. Perhaps that will be the > killer app for IPv6, but I doubt it. My motivation was really to make > incremental progress on eliminating the need for site-local and natting. I think the scope and motivation is very good :) Tim From owner-multi6@ops.ietf.org Mon Jun 21 04:36:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21626 for ; Mon, 21 Jun 2004 04:36:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcKH3-000OUy-PS for multi6-data@psg.com; Mon, 21 Jun 2004 08:35:29 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BcKH2-000OU8-Kg for multi6@ops.ietf.org; Mon, 21 Jun 2004 08:35:29 +0000 Received: (qmail 36706 invoked from network); 21 Jun 2004 08:33:57 -0000 Received: from yahoobb219001188014.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.14) by necom830.hpcl.titech.ac.jp with SMTP; 21 Jun 2004 08:33:57 -0000 Message-ID: <40D69F00.50304@necom830.hpcl.titech.ac.jp> Date: Mon, 21 Jun 2004 17:40:32 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Multi6 , Brian E Carpenter Subject: Re: WG adoption of draft-nordmark-multi6-threats-01.txt References: <40CF2F1E.9010904@zurich.ibm.com> <40D6488A.7010000@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt Erik Lindqvist; >>With no meeting minutes, I don't think any reasoning necessary. > While waiting for official minutes, the Jabber logs can be found here > http://www.xmpp.org/ietf-logs/multi6@ietf.xmpp.org/2004-06-14.html. Jabber logs are not nimutes. > And the drafts are the drafts. You either agree with them or you don't. Brian (and you) wrote: > If you do not agree with this please say so within a week. So, I said so. FYI "this" is not draft itself but adoption of the draft. Masataka Ohta From owner-multi6@ops.ietf.org Mon Jun 21 04:57:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22748 for ; Mon, 21 Jun 2004 04:57:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcKaY-0000jq-4i for multi6-data@psg.com; Mon, 21 Jun 2004 08:55:38 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcKaX-0000j6-7V for multi6@ops.ietf.org; Mon, 21 Jun 2004 08:55:37 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id BFE2B46EA4A; Mon, 21 Jun 2004 10:55:32 +0200 (CEST) In-Reply-To: <40D69F00.50304@necom830.hpcl.titech.ac.jp> References: <40CF2F1E.9010904@zurich.ibm.com> <40D6488A.7010000@necom830.hpcl.titech.ac.jp> <40D69F00.50304@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 , Brian E Carpenter From: Kurt Erik Lindqvist Subject: Re: WG adoption of draft-nordmark-multi6-threats-01.txt Date: Mon, 21 Jun 2004 10:55:27 +0200 To: Masataka Ohta X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-21, at 10.40, Masataka Ohta wrote: > Kurt Erik Lindqvist; > >>> With no meeting minutes, I don't think any reasoning necessary. > >> While waiting for official minutes, the Jabber logs can be found here >> http://www.xmpp.org/ietf-logs/multi6@ietf.xmpp.org/2004-06-14.html. > > Jabber logs are not nimutes. Correct. But I still wanted to point people to them for a transcript of what happened. >> And the drafts are the drafts. You either agree with them or you >> don't. > > Brian (and you) wrote: > >> If you do not agree with this please say so within a week. > > So, I said so. Noted. > FYI "this" is not draft itself but adoption of the draft. Correct. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNaig6arNKXTPFCVEQJiigCeMxdM/2WTLZ1MjRmBUgNZc2qFzBgAoJ6n KMWCMj+K6ZkCIU7MhNw1W7hh =ZZ0K -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Jun 21 04:59:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22873 for ; Mon, 21 Jun 2004 04:59:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcKds-00019r-S6 for multi6-data@psg.com; Mon, 21 Jun 2004 08:59:04 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcKdr-00019V-VX for multi6@ops.ietf.org; Mon, 21 Jun 2004 08:59:04 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 1A19046EA60; Mon, 21 Jun 2004 10:59:02 +0200 (CEST) In-Reply-To: <40D696A0.9070208@cisco.com> References: <5C8469AA-BFB8-11D8-B27A-00039388672E@muada.com> <40D2F867.3050107@cisco.com> <64B7DEE8-C358-11D8-BBC1-000A95928574@kurtis.pp.se> <40D696A0.9070208@cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <3B574328-C361-11D8-BBC1-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 , Iljitsch van Beijnum From: Kurt Erik Lindqvist Subject: Re: draft remarks Date: Mon, 21 Jun 2004 10:58:58 +0200 To: Eliot Lear X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-21, at 10.04, Eliot Lear wrote: > > Kurt Erik Lindqvist wrote: >> While I agree that a must would imply that the document have some >> form or requirements status, referrals are of such a strong demand >> from applications that I think this needs to be addressed one way or >> the other. But at the interim meeting we already said that we would >> try and cover applications requirements in some way. So I agree with >> Iljitsch but I do think that the question should be in the document. >> Perhaps we could also come up with some more sub-questions for this >> point for helping describing exactly how referrals would work. > > Right. What I was aiming for was something along these lines: Ok! - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNajVaarNKXTPFCVEQKcnACeOmLKQOwiJwKZz3Ba1yA3ZyZ0kdIAnR5n h2uFTKQNjAq/6WLYrl5M18Ze =4BDt -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Jun 21 06:27:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28191 for ; Mon, 21 Jun 2004 06:27:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcLzU-000A9n-Fr for multi6-data@psg.com; Mon, 21 Jun 2004 10:25:28 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcLzT-000A9P-A2; Mon, 21 Jun 2004 10:25:27 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5LAOl0A097121; Mon, 21 Jun 2004 12:24:47 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <40D692F9.3000603@cisco.com> References: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> <40D692F9.3000603@cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4E3DBBB8-C36D-11D8-96AB-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 , v6ops@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Date: Mon, 21 Jun 2004 12:25:23 +0200 To: Eliot Lear X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 21-jun-04, at 9:49, Eliot Lear wrote: >> The draft now assumes that having both old and new addresses works, >> and this isn't an assumption you can just make. > No, we assume that the network is in a nominal state prior to > renumbering. The issue you raise below would indicate that perhaps > this *isn't* the case. In which case your problems are bigger than > renumbering. I don't understand what you're getting at. My point is that if you have two prefixes from two ISPs (which I think is the most common situation in renumbering, and it's certainly common enough to be worthy of discussion in a renumbering draft) and both ISPs do ingress filtering (which is also something that can't be discounted) then "turning on" both prefixes at the same time without additional measures is going to lead to problems as packets routed to ISP A may have a source address from the prefix from ISP B (or vice versa) and thus be dropped due to ingress filtering. > We make note of the fact that there is a linkage between the upstream > ISP and the network. What perhaps we should state is that upstreams > may need to know about each other from anti-spoofing mechanism. But what if the ISPs aren't prepared to cooperate? Not everyone is a fortune 1000 company. >> The draft only talks about ingress filtering with regard to security, >> which IMNSHO is stupid because there are no attacks that are possible >> with spoofed addresses that aren't possible with unspoofed addresses. > One of us has missed the point. Firewalls today filter packets based > on destination address. While I would agree that filtering on a > source FROM the Internet would be foolish, different hosts on the > perimeter may require different levels of protection. Regardless, > those rules exist today inside firewalls and would need to be changed, > and that's what we're saying. Yes, but this has very little to do with ingress filtering by ISPs, so the current text obscures the issue rather than illuminate it. >> It's just that tracking the attacks down takes longer. The real issue >> is that you MUST deliver packets to the ISP that matches the source >> address or you have no connecitivity. > This configuration either exists prior to the renumbering events or it > doesn't. If it does it would need to be modified to match the new > addresses. Nonsense. The existence of two prefixes at the same time is exclusively related to renumbering in non-multihomed networks, so it has no relation to the state of the network either before or after renumbering. >> All in all I think this draft is suffering from lack of ambition. >> Either provide some real guidance rather than a bunch of truisms or >> drop the whole thing. > This draft's ambition is to document the process, and perhaps point > out a few areas for improvement in the standards/development front. I > personally think it also shows that the problem is really no less > complex than IPv4, and if we add the MULTI6 fun, we could make it > moreso. Actually it is much less complex unless people extensively use manually configured addresses. The problem with IPv4 is deciding on subnet sizes, merging subnets, avoiding overlap and so on. None of this is an issue with IPv6 since everything fits in a standard issue /64. Obviously there is lots of other stuff that remains the same but what else is new. > Want to make it easier? Great. I'm all ears. There are some pages in my book about renumbering (in IPv4). Feel free to borrow from that (not the literal text, of course). From owner-multi6@ops.ietf.org Mon Jun 21 07:28:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02792 for ; Mon, 21 Jun 2004 07:28:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcMwi-000H52-C3 for multi6-data@psg.com; Mon, 21 Jun 2004 11:26:40 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcMwg-000H4Z-Jc; Mon, 21 Jun 2004 11:26:38 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Jun 2004 04:29:02 +0000 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i5LBPvgI000870; Mon, 21 Jun 2004 04:25:57 -0700 (PDT) Received: from [10.61.124.162] (ams-clip-equant-dhcp-161.cisco.com [10.61.124.162]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id EAA06709; Mon, 21 Jun 2004 04:25:53 -0700 (PDT) Message-ID: <40D6C5BF.8090004@cisco.com> Date: Mon, 21 Jun 2004 13:25:51 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 , v6ops@ops.ietf.org Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) References: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> <40D692F9.3000603@cisco.com> <4E3DBBB8-C36D-11D8-96AB-000A95CD987A@muada.com> In-Reply-To: <4E3DBBB8-C36D-11D8-96AB-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Okay, the confusion in this exchange stems from which "ingress" we were talking about. Iljitsch van Beijnum wrote: > My point is that if you have two prefixes from two ISPs (which I think > is the most common situation in renumbering, and it's certainly common > enough to be worthy of discussion in a renumbering draft) and both ISPs > do ingress filtering (which is also something that can't be discounted) > then "turning on" both prefixes at the same time without additional > measures is going to lead to problems as packets routed to ISP A may > have a source address from the prefix from ISP B (or vice versa) and > thus be dropped due to ingress filtering. Right, I agree. >> We make note of the fact that there is a linkage between the upstream >> ISP and the network. What perhaps we should state is that upstreams >> may need to know about each other from anti-spoofing mechanism. > > > But what if the ISPs aren't prepared to cooperate? Not everyone is a > fortune 1000 company. Okay, I follow you. The draft attempts to cover ground in two areas: 1. That which can be done today; 2. What needs to be fixed. I believe you're arguing for a fix, and perhaps some text in the draft would be good. > >> One of us has missed the point. Firewalls today filter packets based >> on destination address. While I would agree that filtering on a >> source FROM the Internet would be foolish, different hosts on the >> perimeter may require different levels of protection. Regardless, >> those rules exist today inside firewalls and would need to be changed, >> and that's what we're saying. > > > Yes, but this has very little to do with ingress filtering by ISPs, so > the current text obscures the issue rather than illuminate it. Two different points. > >>> It's just that tracking the attacks down takes longer. The real issue >>> is that you MUST deliver packets to the ISP that matches the source >>> address or you have no connecitivity. > > >> This configuration either exists prior to the renumbering events or it >> doesn't. If it does it would need to be modified to match the new >> addresses. > > > Nonsense. The existence of two prefixes at the same time is exclusively > related to renumbering in non-multihomed networks, so it has no relation > to the state of the network either before or after renumbering. Except of course for currently multihomed sites. > Actually it is much less complex unless people extensively use manually > configured addresses. The problem with IPv4 is deciding on subnet sizes, > merging subnets, avoiding overlap and so on. None of this is an issue > with IPv6 since everything fits in a standard issue /64. We have saved network managers from requiring a set of spreadsheet operations. BFD. The level of complexity is substantially the same. > > Obviously there is lots of other stuff that remains the same but what > else is new. > >> Want to make it easier? Great. I'm all ears. > > > There are some pages in my book about renumbering (in IPv4). Feel free > to borrow from that (not the literal text, of course). IPv6 was billed as a great self-configuring does-everything-but-eat follow-on to IPv4. Very little of that is true today. We'd like to identify the mechanisms that would improve matters, at least for IPv6. Who knows? Maybe for IPv4 as well. For instance, what you're looking for above is some way for providers to learn about customers' alternative published connectivity, such as a more robust and accurate RADB in order to configure ingress access-lists. One needs to understand who's authoritative for the information, and what the keys are. Certainly the keys are unlikely to be IP address prefixes :-( As to whether the providers are willing to implement such a mechanism, I can't say. They will look for an easier way, and that easier way today is a NAT that does source selection (policy routing). Eliot From owner-multi6@ops.ietf.org Mon Jun 21 12:41:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01025 for ; Mon, 21 Jun 2004 12:41:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcRqG-000Prc-Dq for multi6-data@psg.com; Mon, 21 Jun 2004 16:40:20 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcRqF-000Pqu-Bh; Mon, 21 Jun 2004 16:40:19 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 21 Jun 2004 09:40:17 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 21 Jun 2004 09:40:14 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 21 Jun 2004 09:40:13 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 21 Jun 2004 09:40:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Date: Mon, 21 Jun 2004 09:40:16 -0700 Message-ID: Thread-Topic: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Thread-Index: AcRXC9V1KF4Dk0vQRh++NXryNVWmCAAoK8ow From: "Christian Huitema" To: "Iljitsch van Beijnum" , "Pekka Savola" Cc: "Ralph Droms" , , "Eliot Lear" , "Multi6" , "Fred Baker" X-OriginalArrivalTime: 21 Jun 2004 16:40:18.0082 (UTC) FILETIME=[6F8F8820:01C457AE] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,RISK_FREE autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Having two prefixes at the same time lands you squarely inside the > domain of draft-huitema-...=20 I actually discussed this point when reviewing an early version of the draft. Fred took the comments into account in section 2.3, "Configuring network elements with the new prefix", and in section 3.3, "Ingress filtering". The text is OK, although it would perhaps be desirable to be a bit more explicit in section 3.3, since there is a way to shoot yourself in the foot. The draft's assumption should be made very clear: * you can shoot yourself in the foot if you route packet to an ISP and that ISP drops them because they fail the ISP ingress filtering test; * we must definitely assume that the new ISP will accept traffic sourced from the old prefix; * the transition works much better if the old ISP accepts traffic from the new prefix, in which case there is no risk of any holes in anyone's foot; * if the old ISP does not accept traffic from the new prefix, then the routing should be updated first: send all the traffic to the new ISP before starting to configure the new addresses. The case that Fred studies is less constrained than the general multi6 problem. Since the goal is to move from a state where all traffic is sent to the old ISP to a state where all traffic is sent to the new one, there is little need to emphasize traffic engineering or load balancing between the two ISP. -- Christian Huitema From owner-multi6@ops.ietf.org Mon Jun 21 13:56:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12072 for ; Mon, 21 Jun 2004 13:56:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcT0U-0008ow-0V for multi6-data@psg.com; Mon, 21 Jun 2004 17:54:58 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcT0T-0008oW-24 for multi6@ops.ietf.org; Mon, 21 Jun 2004 17:54:57 +0000 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5LHrrJ16549; Mon, 21 Jun 2004 10:53:53 -0700 (PDT) Message-ID: <40D72038.7040406@isi.edu> Date: Mon, 21 Jun 2004 10:51:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eliot Lear CC: Kurt Erik Lindqvist , Iljitsch van Beijnum , Multi6 Subject: Re: draft remarks References: <5C8469AA-BFB8-11D8-B27A-00039388672E@muada.com> <40D2F867.3050107@cisco.com> <64B7DEE8-C358-11D8-BBC1-000A95928574@kurtis.pp.se> <40D696A0.9070208@cisco.com> In-Reply-To: <40D696A0.9070208@cisco.com> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD148FFB760A21835CEE7E24D" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD148FFB760A21835CEE7E24D Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Eliot Lear wrote: > > > Kurt Erik Lindqvist wrote: > >> While I agree that a must would imply that the document have some form >> or requirements status, referrals are of such a strong demand from >> applications that I think this needs to be addressed one way or the >> other. But at the interim meeting we already said that we would try >> and cover applications requirements in some way. So I agree with >> Iljitsch but I do think that the question should be in the document. >> Perhaps we could also come up with some more sub-questions for this >> point for helping describing exactly how referrals would work. > > > Right. What I was aiming for was something along these lines: > > Referrals > > How will your solution handle referrals, such as those within FTP or > various conferencing or other peer to peer systems? Also, within a single endsystem (e.g., conventional FTP) or among different endsystems. > Referrals exist within various other protocols, such as so-called > "peer to peer" applications. Note that referrals might suffer three > types of failure: > firewall and NAT - just as FTP active mode experiences today with > relatively simple firewalls? > time-based - is there something ephemeral about the nature of the > solution that might cause a referral (such as a URL) to fail over > time, more so than what we have today? > location-based - if the binding varies based on where the parties > are in the network, if one moves will they no longer be able to > find one another? Or will two parties who aren't moving be able to use exchanged referral info... Joe --------------enigD148FFB760A21835CEE7E24D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFA1yA4E5f5cImnZrsRAqvQAKDlguAQrO4euSyUgIwUQMh9vTT/HACg2hb2 Ys+OFj2AkY3XwXFhQyUKPmk= =4Gkp -----END PGP SIGNATURE----- --------------enigD148FFB760A21835CEE7E24D-- From owner-multi6@ops.ietf.org Tue Jun 22 07:28:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01313 for ; Tue, 22 Jun 2004 07:28:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcjPB-0002mS-46 for multi6-data@psg.com; Tue, 22 Jun 2004 11:25:33 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BcjP9-0002m1-OW for multi6@ops.ietf.org; Tue, 22 Jun 2004 11:25:32 +0000 Received: (qmail 45105 invoked from network); 22 Jun 2004 11:24:18 -0000 Received: from yahoobb219001188014.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.14) by necom830.hpcl.titech.ac.jp with SMTP; 22 Jun 2004 11:24:18 -0000 Message-ID: <40D8185A.7030900@necom830.hpcl.titech.ac.jp> Date: Tue, 22 Jun 2004 20:30:34 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist , address-policy-wg@ripe.net, multi6@ops.ietf.org CC: Gert Doering , Sascha Luck Subject: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> In-Reply-To: <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt Erik Lindqvist; >>If you estimate that you will continue to be very small, you could use >>a /40 or such from one of your upstream ISPs (which is a problem >>*today*, >>as there are not enough upstream ISPs, indeed). > This doesn't fly. He can't set his own routing policy and he can't > multihome. Kurt, as I made presentation in front of you and Brian Carpenter at multi6 WG meeting of IETF58 in Minneapolis on Nov. 2003, it is possible for a small ISP delegated address blocks from multiple larger ISPs and can still have its own policy. Since then, you made no counter argument against my presentation that it is your fallacy to say things against the presentation. For those of you who are not familiar with my (expired) draft used at the meeting, it is available at: http://www.watersprings.org/pub/id/draft-ohta-multihomed-isps-00.txt The interim conclusion of the draft is: Thus, it is not essential that ISPs have their own TLAs. > If he changes the single upstream his customers needs to > renumber. If one changes homing, one needs to renumber, of course. But, it has nothing to do with multihoming or hierarchical ISPs. Just as we shouldn't discourage customers change ISPs, we shouldn't discourage ISPs change upper level ISPs. >>So shall we abandon it? > Yes. No. >> In favour of *what* to replace it? > RIR membership. No. It is proven not to scale. Does it mean that it is beneficial for you if RIRs have more power even though it sacrifices ISPs and users of the Internet by requiring routers with a lot more routing table entries than necessary? Masataka Ohta From owner-multi6@ops.ietf.org Tue Jun 22 08:14:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03532 for ; Tue, 22 Jun 2004 08:14:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bck9H-00094F-8n for multi6-data@psg.com; Tue, 22 Jun 2004 12:13:11 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1Bck97-00092P-7X for multi6@ops.ietf.org; Tue, 22 Jun 2004 12:13:01 +0000 Received: (qmail 45457 invoked from network); 22 Jun 2004 12:11:51 -0000 Received: from yahoobb219001188014.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.14) by necom830.hpcl.titech.ac.jp with SMTP; 22 Jun 2004 12:11:51 -0000 Message-ID: <40D8237D.5020301@necom830.hpcl.titech.ac.jp> Date: Tue, 22 Jun 2004 21:18:05 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Gert Doering CC: Kurt Erik Lindqvist , address-policy-wg@ripe.net, multi6@ops.ietf.org, Sascha Luck Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <20040622114911.GK6204@Space.Net> In-Reply-To: <20040622114911.GK6204@Space.Net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Gert Doering wrote: >>>>In favour of *what* to replace it? >>> >>>RIR membership. >> >>No. It is proven not to scale. > "Proven"? When, where, by whom, based on what data? > > There are less than 10.000 LIRs in existance today, all RIRs combined. According to my upper bound, it's already unnecessarily too large. > 10.000 routing table entries is something far below the near 140.000 we > have today in IPv4. While I'm seriously unhappy with the 140.000 IPv4 > routes, it *does* scale up to fairly insane numbers. Of course, you can have as many routing table entries as you want, as long as backbone routers, speed of which degrade as their routing table bloat, have large enough routing table. However, routing table does cost. High speed memory for backbone routers costs a lot. The cost must be paid by ISPs and, then, by users. If the size of global routing table is limited by a hard upper bound, it simplifies the design of routers a lot (you can put a backbone router (or many of them) with a global routing table in a chip), reduces cost of routers a lot and increases speed of routers a lot. Note that, for scalable (thus, end to end) site multihoming properly work, all the sites are required to circulate global routing table within the sites. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jun 22 08:16:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03699 for ; Tue, 22 Jun 2004 08:16:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BckC1-0009Ue-Kq for multi6-data@psg.com; Tue, 22 Jun 2004 12:16:01 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BckBz-0009UK-NM for multi6@ops.ietf.org; Tue, 22 Jun 2004 12:16:00 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 92B60473CAA; Tue, 22 Jun 2004 14:15:59 +0200 (CEST) In-Reply-To: <40D8185A.7030900@necom830.hpcl.titech.ac.jp> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: address-policy-wg@ripe.net, multi6@ops.ietf.org, Gert Doering , Sascha Luck From: Kurt Erik Lindqvist Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") Date: Tue, 22 Jun 2004 14:15:52 +0200 To: Masataka Ohta X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The following is explicitly not written as co-chair of the IETF multi6 WG. > Kurt, as I made presentation in front of you and Brian > Carpenter at multi6 WG meeting of IETF58 in Minneapolis I think I have seen close to 40 presentations that all would solve the multihoming problem one way or the other, or at least parts of it. > on Nov. 2003, it is possible for a small ISP delegated > address blocks from multiple larger ISPs and can still > have its own policy. It's possible for a small ISP to get several blocks from their upstream, route them inside their network and assign each of their customers with an address out of each of those blocks. Does it scale? Nope. Can it handle failures in the upstream? No. Etc. > Since then, you made no counter argument against my > presentation that it is your fallacy to say things > against the presentation. There are several of the proposals in multi6 that have never received comments, nor support of any kind. > For those of you who are not familiar with my (expired) draft > used at the meeting, it is available at: > > http://www.watersprings.org/pub/id/draft-ohta-multihomed-isps-00.txt > > The interim conclusion of the draft is: > > Thus, it is not essential that ISPs have their own TLAs. Your document does not address the criterias for being classified in a particular category. It does not address what would happen if an ISP grow, get's split/divided. It does not address what the financial models for transit would be. It does not address the non-balance of local vs global traffic coverage. It does not take into account the current peering economics of the Internet. So it's really hard to say anything regarding it. >> If he changes the single upstream his customers needs to >> renumber. > > If one changes homing, one needs to renumber, of course. Which is a limiting factor that I think you will that customers will find unacceptable. > But, it has nothing to do with multihoming or hierarchical > ISPs. > > Just as we shouldn't discourage customers change ISPs, we shouldn't > discourage ISPs change upper level ISPs. Having to renumber when chaining ISPs is not to discourage _change_ of ISP. It's to discourage signing up with that ISP in the first place. >>> In favour of *what* to replace it? > >> RIR membership. > > No. It is proven not to scale. In what way? > Does it mean that it is beneficial for you if RIRs have more > power even though it sacrifices ISPs and users of the Internet > by requiring routers with a lot more routing table entries > than necessary? I am not following this. In what way would the RIRs get more "power"? The policies of the RIRs is set by the RIR community. We are having a lot more routing entries today than we need to, and people seems to think it is a good idea. Actually it is today used to implement policies that follow requirements set by users to their ISPs. Users that pay to get that policy. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgi/aarNKXTPFCVEQIAcQCfYowvBqwQ8MRQusq68q1OBTkKdwkAoPTb zVVRNw/ZJa4p6sGXKMM20RRC =DMSt -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jun 22 08:50:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05444 for ; Tue, 22 Jun 2004 08:50:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bckhk-000Cp6-Fy for multi6-data@psg.com; Tue, 22 Jun 2004 12:48:48 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1Bckhj-000Cop-D0 for multi6@ops.ietf.org; Tue, 22 Jun 2004 12:48:47 +0000 Received: (qmail 45761 invoked from network); 22 Jun 2004 12:47:37 -0000 Received: from yahoobb219001188014.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.14) by necom830.hpcl.titech.ac.jp with SMTP; 22 Jun 2004 12:47:37 -0000 Message-ID: <40D82BE0.90404@necom830.hpcl.titech.ac.jp> Date: Tue, 22 Jun 2004 21:53:52 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: address-policy-wg@ripe.net, multi6@ops.ietf.org, Gert Doering , Sascha Luck Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt Erik Lindqvist; >>Kurt, as I made presentation in front of you and Brian >>Carpenter at multi6 WG meeting of IETF58 in Minneapolis > I think I have seen close to 40 presentations that all would solve the > multihoming problem one way or the other, or at least parts of it. 40? Below is the agenda of the last Minneapolis meeting. Agenda bashing, Chairs (5 min) DT2 Update, David&Marcelo (5 min) DT1 Update, Tony&Iljitsch (5 min) MAST, Dave Crocker (15 min) draft-arifumi-tcp-mh-00, Arifumi Matsumoto (10 min) draft-ohta-multihomed-isps-00, Masataka Ohta (15 min) draft-ohira-assign-select-e2e-multihome-02, Kenji Ohira (10 min) LIN6 update, Masahiro Ishiyama (5 min) draft-nordmark-multi6-threats-00, Erik Nordmark (5 min) draft-nordmark-multi6-noid-01 and draft-nordmark-multi6-sim-01, Erik Nordmark (10 min) Update from chairs and where we go next Open microphone There were a lot less than 40 presentations and the number of proposals was even less. >>on Nov. 2003, it is possible for a small ISP delegated >>address blocks from multiple larger ISPs and can still >>have its own policy. > It's possible for a small ISP to get several blocks from their > upstream, route them inside their network and assign each of their > customers with an address out of each of those blocks. Does it scale? > Nope. Can it handle failures in the upstream? No. Etc. First of all, the small ISPs have multiple upstream ISPs. It is explicitly stated in my draft, which is 3 pages long: It is expected that NLIs have multiple prefixes each belonging to multiple TLAs, all of which is delegated to sites. NLI is an acronym of "Next Level ISP". >>Since then, you made no counter argument against my >>presentation that it is your fallacy to say things >>against the presentation. > There are several of the proposals in multi6 that have never received > comments, nor support of any kind. That's fine, as long as you are indifferent to the issue. However, as you actively made statement against my draft, you are guilty. > Your document does not address the criterias for being classified in a > particular category. My document does address the criteria for being classified in TLI. Classification as NLI is up to TLIs. > It does not address what would happen if an ISP > grow, get's split/divided. No, of course. What if, an ISP having a global routing table entry grow, get's split/divided? The issue is orthogonal to my draft. > It does not address what the financial > models for transit would be. No, of course. It is a policy issue orthogonal to my draft. > It does not address the non-balance of > local vs global traffic coverage. No, of course. For TLI, only the global traffic is important. > It does not take into account the > current peering economics of the Internet. No, of course. It is a policy issue orthogonal to my draft. > So it's really hard to say > anything regarding it. which means you have been indifferent to multi6 issues. >>>If he changes the single upstream his customers needs to >>>renumber. >> >>If one changes homing, one needs to renumber, of course. > Which is a limiting factor that I think you will that customers will > find unacceptable. Huh? What can the customer do, then? Note that it is not acceptable for the customer to switch to other ISP only to change its address. > Having to renumber when chaining ISPs is not to discourage _change_ of > ISP. It's to discourage signing up with that ISP in the first place. What if an ISP bankrupts (like UUNET) and stop operating? Are you saying to discourage signing up with any ISP which may possibly stop operating in the future? Masataka Ohta From owner-multi6@ops.ietf.org Tue Jun 22 09:15:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07437 for ; Tue, 22 Jun 2004 09:15:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bcl6Q-000Fzk-Dq for multi6-data@psg.com; Tue, 22 Jun 2004 13:14:18 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bcl6P-000FzS-12 for multi6@ops.ietf.org; Tue, 22 Jun 2004 13:14:17 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 99E99473EAB; Tue, 22 Jun 2004 15:14:16 +0200 (CEST) In-Reply-To: <40D82BE0.90404@necom830.hpcl.titech.ac.jp> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: address-policy-wg@ripe.net, multi6@ops.ietf.org, Gert Doering , Sascha Luck From: Kurt Erik Lindqvist Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") Date: Tue, 22 Jun 2004 15:14:08 +0200 To: Masataka Ohta X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > There were a lot less than 40 presentations and the number of > proposals was even less. Since the first meeting in Vienna there have been a lot more presentations. I didn't say anything about Minneapolis. Whatever. >>> on Nov. 2003, it is possible for a small ISP delegated >>> address blocks from multiple larger ISPs and can still >>> have its own policy. > >> It's possible for a small ISP to get several blocks from their >> upstream, route them inside their network and assign each of their >> customers with an address out of each of those blocks. Does it scale? >> Nope. Can it handle failures in the upstream? No. Etc. > > First of all, the small ISPs have multiple upstream ISPs. Yes? > It is explicitly stated in my draft, which is 3 pages long: > > It is expected that NLIs have multiple prefixes each belonging to > multiple TLAs, all of which is delegated to sites. > > NLI is an acronym of "Next Level ISP". Yes? And if the end host selects an address that belongs to a TLI that has a internal network failure and the traffic is blaockholed in that providers network, how does the end node find out? TCP timeout? >> There are several of the proposals in multi6 that have never received >> comments, nor support of any kind. > > That's fine, as long as you are indifferent to the issue. I am not. But it's the multi6 WG that will have to end up selecting what to move forward. > However, as you actively made statement against my draft, you > are guilty. "Guilty"!? Whatever. >> Your document does not address the criterias for being classified in a >> particular category. > > My document does address the criteria for being classified in TLI. > > Classification as NLI is up to TLIs. So each TLI can have their own policy for their down-stream NLIs? Who decides who are the TLIs? >> It does not address what would happen if an ISP >> grow, get's split/divided. > > No, of course. > > What if, an ISP having a global routing table entry grow, get's > split/divided? Actually, this is an issue today. Not a complex one, but there is policies in place for it. And if a TLI no longer is a TLI, that will have implications on down-streams. >> It does not address what the financial >> models for transit would be. > > No, of course. > It is a policy issue orthogonal to my draft. Your draft does makes assumptions on how the policy would like. It actually makes assumptions that are very different from the model of today so I think it would be reasonable to explain the thinking. Otherwise I don't think to many ISPs will be interested. >> It does not address the non-balance of >> local vs global traffic coverage. > > No, of course. > > For TLI, only the global traffic is important. What about TLIs that do have large customer bases in local networks? What about very dominant local players that today can force large ISPs to peer simply because of the dominance in particular markets? >> It does not take into account the >> current peering economics of the Internet. > > No, of course. > > It is a policy issue orthogonal to my draft. Again, if you propose something that ignores the polices as they are implemented in todays Internet, I would expect at least some elaboration on how you see todays ISPs adopt this scheme. >> Having to renumber when chaining ISPs is not to discourage _change_ of >> ISP. It's to discourage signing up with that ISP in the first place. > > What if an ISP bankrupts (like UUNET) and stop operating? It creates a nightmare for it's customers. Been there, done that, and have plenty of T-shirts to prove it. I think you miss the point. customers do not want to renumber if their _ISP change upstream_. That have a financial impact on them without them having control of the decision. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgwp6arNKXTPFCVEQIHOgCgzo+9bGXkc8O5A1wwLbC5C5f68/wAoLom neT+RDZlLHxQTDdRyTF+Uq7y =0ZWg -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jun 22 09:21:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07555 for ; Tue, 22 Jun 2004 09:21:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BclCC-000GjM-Hl for multi6-data@psg.com; Tue, 22 Jun 2004 13:20:16 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BclCB-000Gj1-Av for multi6@ops.ietf.org; Tue, 22 Jun 2004 13:20:15 +0000 Received: (qmail 45957 invoked from network); 22 Jun 2004 13:19:06 -0000 Received: from yahoobb219001188014.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.14) by necom830.hpcl.titech.ac.jp with SMTP; 22 Jun 2004 13:19:06 -0000 Message-ID: <40D8333F.8000804@necom830.hpcl.titech.ac.jp> Date: Tue, 22 Jun 2004 22:25:19 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Gert Doering CC: Kurt Erik Lindqvist , address-policy-wg@ripe.net, multi6@ops.ietf.org, Sascha Luck Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <20040622114911.GK6204@Space.Net> <40D8237D.5020301@necom830.hpcl.titech.ac.jp> <20040622123509.GT6204@Space.Net> In-Reply-To: <20040622123509.GT6204@Space.Net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Gert Doering; >>According to my upper bound, it's already unnecessarily too large. > So the *proof* mentioned above consists of "your personal feelings what > the upper limit on the routing table size should be"? No. I gave the upper bound considering the current number of unit of global policies ((UN approved) countries and (self qualified) tier1 providers) and concluded 1000 is large enough. > While I honour your feelings (I also think that the routing table > shouldn't grow out of bounds), this is no "proof" that it's not going > to scale. As you agree that there should be bounds, any policy not incorporating the bounds does not scale. QED. > Also it brings back the problem of "who is worthy enough to receive > one of 8192 TLAs", which was abandoned some 5 years ago, because there > is no entity that can make this decision. But, we have entities to define address allocation rules. So, it is merely an issue to have an agreeable rule. For example, assign 3 TLAs to NICs operating ccTLDs. NICs of countries are assigned one more for each population of 10 million. Then, have 500 for initial auction with lease period of a year with 10 more supplied monthly for 5 years. There will be about 2,000 TLAs, yet. > Of course. But I tend to believe if people tell me "10k routes are no > problem today". Oliver is building routers, with fast memory, and > good routing table lookup algorithms. Be careful. I'm not offending Oliver. But, it should be noted that, in general, router vendors, especially large ones, want to keep their product as expensive as possible. And, now, though I may offend Oliver, router engineers do their work in a way they have been doing. So, it is possible to have a router with 10k routes today and tomorrow. But, it will costs almost as much as today even in tomorrow. However, it is a lot less expensive if global routing can be performed only by looking 13 bits of the address. There is no associative memory necessary. It's just a memory of 8K entry with no associativity. I think it is still reasonable to have an associative memory of, say, 1K entry, for local routing. > Today, high end routers can handle 140k routes. How much does it costs? How much do low end routers with 1G ethernet interfaces costs? >>If the size of global routing table is limited by a hard upper >>bound, it simplifies the design of routers a lot (you can put >>a backbone router (or many of them) with a global routing table >>in a chip), reduces cost of routers a lot and increases speed >>of routers a lot. > This is not going to work. *Inside* your AS, you will always have > some more routes, Sure. It does work. See above. > and depending on the quality of your IGP aggregation, > you might easily end up with more than 10k *internal* routes. It's a poor operation, which costs. > So no matter what upper bound you put on the external routes, you > cannot assume that nobody will ever need more routing table entries. Those requiring a lot IGP entries should pay the cost by themselves. > Out of interest: what number do you suggest for the hard upper bound? 8K for the global routing table, though I think, with reasons, 1K is large enough. >>Note that, for scalable (thus, end to end) site multihoming properly >>work, all the sites are required to circulate global routing table >>within the sites. > Actually, no. Not even in IPv4 today (which is part of the problem, > that you can inject your prefix from a Cisco 2500 router, while > everyone else needs to buy $costly hardware to *carry* your prefix). Yes and no. IPv4 today is hopeless, because of legacy randomized allocation of class Cs, which is why multi6 is not multi4. The charter of multi6 says: but IPv6 represents an opportunity for more scalable approaches. IPv6 differs from IPv4 in ways that may allow for different approaches to multihoming that are not immediately applicable to IPv4. relatively few IPv6 address blocks have been given out (i.e., there are no issues with legacy allocations as in IPv4). Masataka Ohta From owner-multi6@ops.ietf.org Tue Jun 22 09:56:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09764 for ; Tue, 22 Jun 2004 09:56:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bcljl-000LaQ-FL for multi6-data@psg.com; Tue, 22 Jun 2004 13:54:57 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1Bcljc-000LXs-9l for multi6@ops.ietf.org; Tue, 22 Jun 2004 13:54:48 +0000 Received: (qmail 46183 invoked from network); 22 Jun 2004 13:53:39 -0000 Received: from yahoobb219001188014.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.14) by necom830.hpcl.titech.ac.jp with SMTP; 22 Jun 2004 13:53:39 -0000 Message-ID: <40D83B58.90906@necom830.hpcl.titech.ac.jp> Date: Tue, 22 Jun 2004 22:59:52 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: address-policy-wg@ripe.net, multi6@ops.ietf.org, Gert Doering , Sascha Luck Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> In-Reply-To: <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt Erik Lindqvist; >>>It's possible for a small ISP to get several blocks from their >>>upstream, route them inside their network and assign each of their >>>customers with an address out of each of those blocks. Does it scale? >>>Nope. Can it handle failures in the upstream? No. Etc. >> >>First of all, the small ISPs have multiple upstream ISPs. > > > Yes? It does scale. It can handle failures in the upstream. >>It is explicitly stated in my draft, which is 3 pages long: >> >> It is expected that NLIs have multiple prefixes each belonging to >> multiple TLAs, all of which is delegated to sites. >> >>NLI is an acronym of "Next Level ISP". > Yes? And if the end host selects an address that belongs to a TLI that > has a internal network failure and the traffic is blaockholed in that > providers network, how does the end node find out? TCP timeout? Read the draft of end to end multihoming. It is an issue of transport/application layer. Application running over TCP can use default TCP timeout or modify it. Application may use UDP with its own timeout. >>>There are several of the proposals in multi6 that have never received >>>comments, nor support of any kind. >> >>That's fine, as long as you are indifferent to the issue. > I am not. You have been. > But it's the multi6 WG that will have to end up selecting > what to move forward. It's your problem that you failed to properly control the WG. > "Guilty"!? Whatever. See the subject. > So each TLI can have their own policy for their down-stream NLIs? Who > decides who are the TLIs? If you need an example policy, read the draft. >>>It does not address what would happen if an ISP >>>grow, get's split/divided. >> >>No, of course. >> >>What if, an ISP having a global routing table entry grow, get's >>split/divided? > > > Actually, this is an issue today. Not a complex one, but there is > policies in place for it. And if a TLI no longer is a TLI, that will > have implications on down-streams. Sure. So, even if you directly subscribe to an TLI, you may have to renumber. Fair enough. > Your draft does makes assumptions on how the policy would like. My draft does not make any assumption on how the policy would like. You failed to give specific example for counter argument. >>>It does not address the non-balance of >>>local vs global traffic coverage. > What about TLIs that do have large customer bases in local networks? > What about very dominant local players that today can force large ISPs > to peer simply because of the dominance in particular markets? Dominant local players may be treated as NLI or it can be an independent TLI. I know Yahoo, for example, has certain influence on its ISPs. >>It is a policy issue orthogonal to my draft. > Again, if you propose something that ignores the polices as they are > implemented in todays Internet, I would expect at least some > elaboration on how you see todays ISPs adopt this scheme. I do recognize the policies and says them orthogonal. >>What if an ISP bankrupts (like UUNET) and stop operating? > > > It creates a nightmare for it's customers. Been there, done that, and > have plenty of T-shirts to prove it. I think you miss the point. > customers do not want to renumber if their _ISP change upstream_. That > have a financial impact on them without them having control of the > decision. You miss the point. I'm saying all the ISPs have chance to change its prefix. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jun 22 10:15:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11180 for ; Tue, 22 Jun 2004 10:15:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bcm2a-000P89-Ud for multi6-data@psg.com; Tue, 22 Jun 2004 14:14:24 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bcm2Z-000P7P-9Q for multi6@ops.ietf.org; Tue, 22 Jun 2004 14:14:23 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 4FA8B474086; Tue, 22 Jun 2004 16:14:22 +0200 (CEST) In-Reply-To: <40D83B58.90906@necom830.hpcl.titech.ac.jp> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: address-policy-wg@ripe.net, multi6@ops.ietf.org, Gert Doering , Sascha Luck From: Kurt Erik Lindqvist Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") Date: Tue, 22 Jun 2004 16:14:19 +0200 To: Masataka Ohta X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> It is explicitly stated in my draft, which is 3 pages long: >>> >>> It is expected that NLIs have multiple prefixes each belonging to >>> multiple TLAs, all of which is delegated to sites. >>> >>> NLI is an acronym of "Next Level ISP". > >> Yes? And if the end host selects an address that belongs to a TLI that >> has a internal network failure and the traffic is blaockholed in that >> providers network, how does the end node find out? TCP timeout? > > Read the draft of end to end multihoming. Ok, so you are actually proposing that we a) Change the allocation policies according to draft-ohta-multihomed-isps-00.txt and b) Adopt the mechanisms in draft-ohta-e2e-multihoming-06.txt ? > It is an issue of transport/application layer. So we need to modify the application layer according to the e2e draft? > Application may use UDP with its own timeout. So all UDP applications need to modified (or not used at multihomed sites)? >> But it's the multi6 WG that will have to end up selecting >> what to move forward. > > It's your problem that you failed to properly control the WG. This is a discussion that doesn't belong here, but it's not the role of the WG chairs to control the WG. It's the chairs job to conclude what solutions there are support for and which ones there are not. This is the reason for the classification of solutions sent to the multi6 WG and the statement that many of them simply do not have any support. >> So each TLI can have their own policy for their down-stream NLIs? Who >> decides who are the TLIs? > > If you need an example policy, read the draft. Make a bidding round for the TLI roles? So you want an open market for default-free address space? >>>> It does not address the non-balance of >>>> local vs global traffic coverage. > >> What about TLIs that do have large customer bases in local networks? >> What about very dominant local players that today can force large ISPs >> to peer simply because of the dominance in particular markets? > > Dominant local players may be treated as NLI or it can be an > independent TLI. > > I know Yahoo, for example, has certain influence on its ISPs. So Yahoo would qualify as a TLI? If they won a TLI assignment in the bidding round? While for example NTT might not? >>> It is a policy issue orthogonal to my draft. > >> Again, if you propose something that ignores the polices as they are >> implemented in todays Internet, I would expect at least some >> elaboration on how you see todays ISPs adopt this scheme. > > I do recognize the policies and says them orthogonal. Well, the bidding for address space has a large chance to off-set the financial models of the Internet today. >> It creates a nightmare for it's customers. Been there, done that, and >> have plenty of T-shirts to prove it. I think you miss the point. >> customers do not want to renumber if their _ISP change upstream_. That >> have a financial impact on them without them having control of the >> decision. > > You miss the point. I'm saying all the ISPs have chance to change > its prefix. Why would customers go to NLIs in the first place? I for one would only by service from TLIs. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNg+vqarNKXTPFCVEQKuBgCfThWCvXgCnbYfsyFvRFxUlBsbnMUAn3hs LKmspmiIwsGGSWDu80HV4m56 =lPg6 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jun 22 10:24:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12321 for ; Tue, 22 Jun 2004 10:24:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcmC2-0000hb-9f for multi6-data@psg.com; Tue, 22 Jun 2004 14:24:10 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcmC1-0000hC-Ez for multi6@ops.ietf.org; Tue, 22 Jun 2004 14:24:09 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 22 Jun 2004 07:26:22 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5MENo72014968; Tue, 22 Jun 2004 07:24:01 -0700 (PDT) Received: from [144.254.23.182] (dhcp-data-vlan10-23-182.cisco.com [144.254.23.182]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA22181; Tue, 22 Jun 2004 07:23:48 -0700 (PDT) Message-ID: <40D840F2.4080109@cisco.com> Date: Tue, 22 Jun 2004 16:23:46 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masataka Ohta CC: Kurt Erik Lindqvist , address-policy-wg@ripe.net, multi6@ops.ietf.org, Gert Doering , Sascha Luck Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> In-Reply-To: <40D83B58.90906@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ohta-san, Which part of your previous message provides me guidance on how your solution will solve scaling problems? Eliot From owner-multi6@ops.ietf.org Tue Jun 22 10:48:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13879 for ; Tue, 22 Jun 2004 10:48:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcmXq-0003aq-Ei for multi6-data@psg.com; Tue, 22 Jun 2004 14:46:42 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BcmXp-0003aZ-BT for multi6@ops.ietf.org; Tue, 22 Jun 2004 14:46:41 +0000 Received: (qmail 46580 invoked from network); 22 Jun 2004 14:45:33 -0000 Received: from yahoobb219001188014.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.14) by necom830.hpcl.titech.ac.jp with SMTP; 22 Jun 2004 14:45:33 -0000 Message-ID: <40D84781.8020604@necom830.hpcl.titech.ac.jp> Date: Tue, 22 Jun 2004 23:51:45 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: address-policy-wg@ripe.net, multi6@ops.ietf.org, Gert Doering , Sascha Luck Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> In-Reply-To: <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt Erik Lindqvist; >>>>It is explicitly stated in my draft, which is 3 pages long: >>>> >>>> It is expected that NLIs have multiple prefixes each belonging to >>>> multiple TLAs, all of which is delegated to sites. >>>> >>>>NLI is an acronym of "Next Level ISP". >> >>>Yes? And if the end host selects an address that belongs to a TLI that >>>has a internal network failure and the traffic is blaockholed in that >>>providers network, how does the end node find out? TCP timeout? >> >>Read the draft of end to end multihoming. > > > Ok, so you are actually proposing that we I'm actually proposing that you read the draft, if you are interested in multi6 issues. Then, if you have any question, ask, hopefully with proper quoting of the draft. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jun 22 10:58:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14423 for ; Tue, 22 Jun 2004 10:58:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bcmhe-0004w4-TG for multi6-data@psg.com; Tue, 22 Jun 2004 14:56:50 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1Bcmhd-0004va-RG for multi6@ops.ietf.org; Tue, 22 Jun 2004 14:56:50 +0000 Received: (qmail 46664 invoked from network); 22 Jun 2004 14:55:41 -0000 Received: from yahoobb219001188014.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.14) by necom830.hpcl.titech.ac.jp with SMTP; 22 Jun 2004 14:55:41 -0000 Message-ID: <40D849E2.6010105@necom830.hpcl.titech.ac.jp> Date: Wed, 23 Jun 2004 00:01:54 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: address-policy-wg@ripe.net, multi6@ops.ietf.org, Gert Doering , Sascha Luck Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> In-Reply-To: <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt Erik Lindqvist; >>Application may use UDP with its own timeout. > So all UDP applications need to modified (or not used at multihomed > sites)? If there is a family of UDP applications sharing the same idea on "connection", there can be a set of connection management library functions shared by the applications. Then, it may be that only the library may be modified. > This is a discussion that doesn't belong here, but it's not the role of > the WG chairs to control the WG. Then, it was your mistake that you controlled the WG to forbid presentations of proposals. > Make a bidding round for the TLI roles? So you want an open market for > default-free address space? Read the draft for an example. It does not say "open". > So Yahoo would qualify as a TLI? If they won a TLI assignment in the > bidding round? While for example NTT might not? Read the draft. >>I do recognize the policies and says them orthogonal. > Well, the bidding for address space has a large chance to off-set the > financial models of the Internet today. As explained in my presentation, it does not. > Why would customers go to NLIs in the first place? I for one would only > by service from TLIs. It is you who are ignoring the reality. Why do customers today buy service from tier2 providers? Masataka Ohta From owner-multi6@ops.ietf.org Tue Jun 22 11:01:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14623 for ; Tue, 22 Jun 2004 11:01:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bcmlw-0005gz-5e for multi6-data@psg.com; Tue, 22 Jun 2004 15:01:16 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1Bcmlv-0005gN-29 for multi6@ops.ietf.org; Tue, 22 Jun 2004 15:01:15 +0000 Received: (qmail 46707 invoked from network); 22 Jun 2004 15:00:07 -0000 Received: from yahoobb219001188014.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.14) by necom830.hpcl.titech.ac.jp with SMTP; 22 Jun 2004 15:00:07 -0000 Message-ID: <40D84AEB.4090101@necom830.hpcl.titech.ac.jp> Date: Wed, 23 Jun 2004 00:06:19 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Eliot Lear CC: Kurt Erik Lindqvist , address-policy-wg@ripe.net, multi6@ops.ietf.org, Gert Doering , Sascha Luck Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <40D840F2.4080109@cisco.com> In-Reply-To: <40D840F2.4080109@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot Lear; Hi, > Which part of your previous message provides me guidance on how your > solution will solve scaling problems? Scaling problems of which? If we have hard limit on the global routing table size, there is no scaling problem on the global routing table size. The question is whether we can put the limit or not. Considering that the global routing table entries are for global policy control, we don't need so much entries much more than those having real global policy, that is, (self qualified) tier1. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jun 22 11:22:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15839 for ; Tue, 22 Jun 2004 11:22:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bcn5h-0009AB-Gg for multi6-data@psg.com; Tue, 22 Jun 2004 15:21:41 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bcn5f-00099j-Sk for multi6@ops.ietf.org; Tue, 22 Jun 2004 15:21:40 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5MFKdGP112998; Tue, 22 Jun 2004 15:20:39 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5MFKd5m210118; Tue, 22 Jun 2004 17:20:39 +0200 Received: from zurich.ibm.com (brc.watson.ibm.com [9.2.240.32]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA171108; Tue, 22 Jun 2004 17:20:37 +0200 Message-ID: <40D84E40.1080304@zurich.ibm.com> Date: Tue, 22 Jun 2004 17:20:32 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Masataka Ohta CC: Kurt Erik Lindqvist , address-policy-wg@ripe.net, multi6@ops.ietf.org, Gert Doering , Sascha Luck Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> In-Reply-To: <40D849E2.6010105@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Since Kurtis took off his co-chair hat for this thread, I will put mine on. This is not a fruitful discussion, and it certainly should not be cross-posted. As Kurtis said, there have been no indications of support for Masataka's draft in multi6, so subject to the minutes of the recent meeting being sent to the list and agreed, it is off the table. Since multi6 has not firmly identified a solutions direction, and no work on a specific solution is chartered in the IETF yet, it's premature to discuss possible impact of multi6 on RIR policy. Brian multi6 WG co-chair Masataka Ohta wrote: > Kurt Erik Lindqvist; > > >>>Application may use UDP with its own timeout. > > >>So all UDP applications need to modified (or not used at multihomed >>sites)? > > > If there is a family of UDP applications sharing the same > idea on "connection", there can be a set of connection > management library functions shared by the applications. > Then, it may be that only the library may be modified. > > >>This is a discussion that doesn't belong here, but it's not the role of >>the WG chairs to control the WG. > > > Then, it was your mistake that you controlled the WG to forbid > presentations of proposals. > > >>Make a bidding round for the TLI roles? So you want an open market for >>default-free address space? > > > Read the draft for an example. It does not say "open". > > >>So Yahoo would qualify as a TLI? If they won a TLI assignment in the >>bidding round? While for example NTT might not? > > > Read the draft. > > >>>I do recognize the policies and says them orthogonal. > > >>Well, the bidding for address space has a large chance to off-set the >>financial models of the Internet today. > > > As explained in my presentation, it does not. > > >>Why would customers go to NLIs in the first place? I for one would only >>by service from TLIs. > > > It is you who are ignoring the reality. > > Why do customers today buy service from tier2 providers? > > Masataka Ohta > > > From owner-multi6@ops.ietf.org Tue Jun 22 11:27:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16474 for ; Tue, 22 Jun 2004 11:27:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcnAp-0009kP-48 for multi6-data@psg.com; Tue, 22 Jun 2004 15:26:59 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BcnAo-0009jy-2B for multi6@ops.ietf.org; Tue, 22 Jun 2004 15:26:58 +0000 Received: (qmail 46881 invoked from network); 22 Jun 2004 15:25:49 -0000 Received: from yahoobb219001188014.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.14) by necom830.hpcl.titech.ac.jp with SMTP; 22 Jun 2004 15:25:49 -0000 Message-ID: <40D850F2.4000701@necom830.hpcl.titech.ac.jp> Date: Wed, 23 Jun 2004 00:32:02 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Kurt Erik Lindqvist , address-policy-wg@ripe.net, multi6@ops.ietf.org, Gert Doering , Sascha Luck Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <40D84E40.1080304@zurich.ibm.com> In-Reply-To: <40D84E40.1080304@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter; > As Kurtis said, there have been no indications of support > for Masataka's draft in multi6, As you give no chance to discuss it at the meeting, it is not a valid decision. > so subject to the minutes of > the recent meeting being sent to the list and agreed, > it is off the table. Thank you for yet another demonstration of poor chairing. WG can't decide something at the meeting. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jun 22 12:09:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18431 for ; Tue, 22 Jun 2004 12:09:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcnnQ-000F1b-Mu for multi6-data@psg.com; Tue, 22 Jun 2004 16:06:52 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcnnP-000F1J-Rz for multi6@ops.ietf.org; Tue, 22 Jun 2004 16:06:52 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 8DBAF474703; Tue, 22 Jun 2004 18:06:52 +0200 (CEST) In-Reply-To: <40D84781.8020604@necom830.hpcl.titech.ac.jp> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: address-policy-wg@ripe.net, multi6@ops.ietf.org, Gert Doering , Sascha Luck From: Kurt Erik Lindqvist Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") Date: Tue, 22 Jun 2004 18:06:48 +0200 To: Masataka Ohta X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 16.51, Masataka Ohta wrote: >> Ok, so you are actually proposing that we > > I'm actually proposing that you read the draft, if you > are interested in multi6 issues. For the record for the RIPE address policy WG, I will take this discussion over to multi6 only. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNhZG6arNKXTPFCVEQLyCQCeMpcC0HeHQ5kwbyosKArIwO8zoosAn1PM VjC50f6zfRPocE5XrfPG9Zc1 =bva4 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jun 22 12:23:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19455 for ; Tue, 22 Jun 2004 12:23:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bco2p-000H45-GM for multi6-data@psg.com; Tue, 22 Jun 2004 16:22:47 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bco2n-000H3U-TA for multi6@ops.ietf.org; Tue, 22 Jun 2004 16:22:46 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5MGMjGP110250 for ; Tue, 22 Jun 2004 16:22:45 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5MGMiMS170920 for ; Tue, 22 Jun 2004 18:22:44 +0200 Received: from zurich.ibm.com (brc.watson.ibm.com [9.2.240.32]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id SAA49716 for ; Tue, 22 Jun 2004 18:22:43 +0200 Message-ID: <40D85CCE.5010507@zurich.ibm.com> Date: Tue, 22 Jun 2004 18:22:38 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <40D84E40.1080304@zurich.ibm.com> <40D850F2.4000701@necom830.hpcl.titech.ac.jp> In-Reply-To: <40D850F2.4000701@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka Ohta wrote: > Brian E Carpenter; > > >>As Kurtis said, there have been no indications of support >>for Masataka's draft in multi6, > > > As you give no chance to discuss it at the meeting, it is > not a valid decision. > No solutions drafts were discussed in detail at the meeting. As you can tell from the agenda, the MP3 archive, and the jabber log, and will see in the minutes, we analyzed the classes of solutions. > >>so subject to the minutes of >>the recent meeting being sent to the list and agreed, >>it is off the table. > > > Thank you for yet another demonstration of poor chairing. > > WG can't decide something at the meeting. No, this is an example of correct chairing. The consensus formed in the meeting will be recorded in the draft minutes, and the draft minutes will be sent to this list for validation of the consensus on the list. It takes longer to prepare the minutes of a full day's meeting than those of a normal IETF session, especially when distracted by impolite emails. I have deleted your inappropriate cross-postings. Brian From owner-multi6@ops.ietf.org Tue Jun 22 14:36:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14542 for ; Tue, 22 Jun 2004 14:36:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bcq6S-0008YG-ND for multi6-data@psg.com; Tue, 22 Jun 2004 18:34:40 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1Bcq6J-0008XK-JB for multi6@ops.ietf.org; Tue, 22 Jun 2004 18:34:31 +0000 Received: (qmail 48007 invoked from network); 22 Jun 2004 18:33:26 -0000 Received: from yahoobb219001188014.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.14) by necom830.hpcl.titech.ac.jp with SMTP; 22 Jun 2004 18:33:26 -0000 Message-ID: <40D87CE8.7010909@necom830.hpcl.titech.ac.jp> Date: Wed, 23 Jun 2004 03:39:36 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Multi6 List Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <6FAEC6CE-C467-11D8-860C-000A95928574@kurtis.pp.se> In-Reply-To: <6FAEC6CE-C467-11D8-860C-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt Erik Lindqvist; >>Read the draft. > Several times today alone, otherwise I wouldn't remember what it said. OK. > If we concentrate on the draft-ohta-multihomed-isps-00.txt proposal > alone : That's fine. The architectural draft is not essential for today's topic. > If I pick a Tier-2 or Tier-3 provider, I will in most > cases get addresses provided out of their PA allocation. Seemingly, you think that NLIs peering with a TLI must be delegated TLI's prefix. However, ISPs are still free to peer with any other ISPs without sharing a prefix. Though it increases number of prefixes within ISPs it is a local policy issue of ISPs on how much extra prifixes they carry. The requirement, instead, is that NLIs delegated a TLI's prefix must peer with the TLI, not vice versa. Thus, your original statement: >>This doesn't fly. He can't set his own routing policy and he can't >> multihome. is wrong and the remaining issue is renumbering. >> If he changes the single upstream his customers needs to >> renumber. That is true on any upstream prefix change, though adding a TLI as a peer does not necessarily mean adding a prefix. Then, you miss one thing. There supposed to be a hard limit on the number of TLAs. Considering that there will be new TLIs, old TLIs must retire. Thus, no TLI is assured to remain to be TLI forever. I > I, as a customer, would then much rather be a customer of > the TLI directly, that would assure me that I would have stable > addresses, There is no such stability assured. > That > allocation is permanent with the ISP as long as they exist and pays > their RIR (and in most cases long after they don't pay their RIR). That is the assumption which is no longer valid with the introduction of the hard limit on the number of global routing table size. ISP hierarchy is inessential. So is the theory. Now, consider the reality. If the hard limit is large enough (I think 8192 is so), TLI changes will be infrequent. TLA allocation policy should have mechanism to allow an ISP recover from accidental loss of TLI status. For example, an ISP may be allowed to use its TLA one year after its lease period has expired and to continue to use it (with penalty fee or something like that) if the ISP recover its TLI status witin a year. NLIs seldom change their set of prefixes for obviouis commercial reasons. Even if they do, there will be long notification and transition periods. End users are free not to add new prefix, though they sacrifice some robustness. When a prefix from a TLI is deleted, NLIs with good economical condition will immediately stop advertising old prefix to end users but keep peering with the TLI and keep routing packets with old prefix for the time being. Thus, end users can keep using the old prefix. On the other hand, ISPs (including TLIs) without good economical conditios will keep bankrupting and stopping operations without much prior notices, which has nothing to do with the addressing architecture. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jun 22 14:49:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17276 for ; Tue, 22 Jun 2004 14:49:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcqK3-000AL2-89 for multi6-data@psg.com; Tue, 22 Jun 2004 18:48:43 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcqK1-000AKl-QP for multi6@ops.ietf.org; Tue, 22 Jun 2004 18:48:42 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5MIoBIv028198 for ; Tue, 22 Jun 2004 20:50:11 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <40D8333F.8000804@necom830.hpcl.titech.ac.jp> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <20040622114911.GK6204@Space.Net> <40D8237D.5020301@necom830.hpcl.titech.ac.jp> <20040622123509.GT6204@Space.Net> <40D8333F.8000804@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: optimum routing table size Date: Tue, 22 Jun 2004 20:48:39 +0200 To: Multi6 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 22-jun-04, at 15:25, Masataka Ohta wrote: > However, it is a lot less expensive if global routing can be > performed only by looking 13 bits of the address. > There is no associative memory necessary. > It's just a memory of 8K entry with no associativity. > I think it is still reasonable to have an associative memory > of, say, 1K entry, for local routing. Most routers don't use associative memory or CAMs for routing table lookups, this is mostly done for layer 2 switching. In addition to using a CAM, obviously any kind of data structure can be used to store routing information, such as linked lists (not efficient as they must be searched serially), arrays or various types of trees. Vendors such as Cisco and Juniper use n-way tries for this, which is generally quite efficient even for lookups in very large tables. (Note though that looking up routes for the purpose of forwarding is not the main operational issue with a large routing table, as this scales at worst at O(log(n)): the real problem is processing updates, which scales at O(log(n)*n), and convergence times after links come up or go down, which scale linearly.) I don't think CAMs are the right solution, as they are very inflexible and also very power-hungry. If a more efficient lookup mechanism is desired, it would probably make sense to see if it's possible to store the routing table in a flat array. This way, looking up a route always takes one memory cycle, it doesn't get much better than that. Obviously then the routing table must fit in memory, which means the longest prefixes that can be looked up this way are in the order of 26 bits. This is pretty close to the length of prefixes given out by the RIRs. In any event, I think putting an artificial limit on the size of the routing table is probably more harmful than useful, especially in the long run and/or if the limit is quite low such as 8k. A more fruitful approach would be to look at mechanisms to remove unnecessary routing information from routing tables. The obvious way to do this would be to take advantage of geographic grouping of prefixes where possible. From owner-multi6@ops.ietf.org Tue Jun 22 15:25:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22281 for ; Tue, 22 Jun 2004 15:25:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bcqsl-000Eul-0A for multi6-data@psg.com; Tue, 22 Jun 2004 19:24:35 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1Bcqsj-000EuI-7c for multi6@ops.ietf.org; Tue, 22 Jun 2004 19:24:33 +0000 Received: (qmail 48294 invoked from network); 22 Jun 2004 19:23:28 -0000 Received: from yahoobb219001188014.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.14) by necom830.hpcl.titech.ac.jp with SMTP; 22 Jun 2004 19:23:28 -0000 Message-ID: <40D888A1.7070901@necom830.hpcl.titech.ac.jp> Date: Wed, 23 Jun 2004 04:29:37 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Gert Doering CC: Kurt Erik Lindqvist , address-policy-wg@ripe.net, multi6@ops.ietf.org, Sascha Luck Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> In-Reply-To: <20040622185835.GC6204@Space.Net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Gert Doering; Hi, > Something that right now confuses *me* is: If I understand this > correctly, the 'default-free zone' is meant to be kept below 1000 > routes, so routers can be fast. The hard limit is, IMO, 8192. > But what about the internal > structure of all these networks? At least the "internal core" boxes > need to know all routes for the "NLI"s (or the NLIs' customers), which > might well be many 1000s... You are right. There is nothing mentioned in the draft, but I suggested 1000 today, which I still think enough for TLI internal, but should not be enough for NLI. Do you have any suggestion? Note that routers in NLIs may have less performance than those in TLIs. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jun 22 16:07:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25200 for ; Tue, 22 Jun 2004 16:07:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcrX3-000Jfa-OG for multi6-data@psg.com; Tue, 22 Jun 2004 20:06:13 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BcrX2-000JfH-LJ for multi6@ops.ietf.org; Tue, 22 Jun 2004 20:06:12 +0000 Received: (qmail 48366 invoked from network); 22 Jun 2004 19:38:27 -0000 Received: from yahoobb219001188014.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.14) by necom830.hpcl.titech.ac.jp with SMTP; 22 Jun 2004 19:38:27 -0000 Message-ID: <40D88C21.6030208@necom830.hpcl.titech.ac.jp> Date: Wed, 23 Jun 2004 04:44:33 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 Subject: Re: optimum routing table size References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <20040622114911.GK6204@Space.Net> <40D8237D.5020301@necom830.hpcl.titech.ac.jp> <20040622123509.GT6204@Space.Net> <40D8333F.8000804@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; >> I think it is still reasonable to have an associative memory >> of, say, 1K entry, for local routing. > Most routers don't use associative memory or CAMs for routing table > lookups, this is mostly done for layer 2 switching. It is because CAM is not large enough for the global routing table. Let's assume that the number of local route is smaller than CAM size. > In addition to using a CAM, obviously any kind of data structure can be > used to store routing information, such as linked lists (not efficient > as they must be searched serially), arrays or various types of trees. > Vendors such as Cisco and Juniper use n-way tries for this, which is > generally quite efficient even for lookups in very large tables. 1K CAM is very fast. > (Note though that looking up routes for the purpose of forwarding is not > the main operational issue with a large routing table, as this scales at > worst at O(log(n)): Note that the amount of hardware is O(n). Note that it costs more than O(log(n)) times to make already fast memory O(log(n)) times faster. Note that, with planar layout, there is O(sqrt(n)) factor. > the real problem is processing updates, which scales > at O(log(n)*n), and convergence times after links come up or go down, > which scale linearly.) Yup. > I don't think CAMs are the right solution, as they are very inflexible Consider a router on a chip, which is very inflexible, anyway. A router in a chip is a lot more faster than a router on two chips. > and also very power-hungry. If a more efficient lookup mechanism is > desired, it would probably make sense to see if it's possible to store > the routing table in a flat array. TLA addresses are supposed to be accessed so. > This way, looking up a route always > takes one memory cycle, it doesn't get much better than that. Obviously > then the routing table must fit in memory, which means the longest > prefixes that can be looked up this way are in the order of 26 bits. Large memory is slow. Note also your comment on BGP convergence. > In any event, I think putting an artificial limit on the size of the > routing table is probably more harmful than useful, especially in the > long run and/or if the limit is quite low such as 8k. Why do you think 8k quite low? > A more fruitful approach would be to look at mechanisms to remove > unnecessary routing information from routing tables. The obvious way to > do this would be to take advantage of geographic grouping of prefixes > where possible. Then, how may route, do you think, is enough? Masataka Ohta From owner-multi6@ops.ietf.org Tue Jun 22 17:56:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01253 for ; Tue, 22 Jun 2004 17:56:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BctEW-0005sC-Ul for multi6-data@psg.com; Tue, 22 Jun 2004 21:55:12 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BctES-0005rK-6G for multi6@ops.ietf.org; Tue, 22 Jun 2004 21:55:10 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5MLt3GP111406 for ; Tue, 22 Jun 2004 21:55:03 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5MLt25m279152 for ; Tue, 22 Jun 2004 23:55:03 +0200 Received: from zurich.ibm.com (brc.watson.ibm.com [9.2.240.32]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA23306 for ; Tue, 22 Jun 2004 23:55:01 +0200 Message-ID: <40D8AAB1.3040203@zurich.ibm.com> Date: Tue, 22 Jun 2004 23:54:57 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 List Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <6FAEC6CE-C467-11D8-860C-000A95928574@kurtis.pp.se> <40D87CE8.7010909@necom830.hpcl.titech.ac.jp> In-Reply-To: <40D87CE8.7010909@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > There supposed to be a hard limit on the number of TLAs. The concept of TLAs was removed from the IPv6 architecture quite some time ago. Brian From owner-multi6@ops.ietf.org Tue Jun 22 17:57:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01271 for ; Tue, 22 Jun 2004 17:57:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BctEd-0005tH-H8 for multi6-data@psg.com; Tue, 22 Jun 2004 21:55:19 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BctEU-0005rW-EB for multi6@ops.ietf.org; Tue, 22 Jun 2004 21:55:10 +0000 Received: (qmail 48943 invoked from network); 22 Jun 2004 21:54:07 -0000 Received: from yahoobb219001188014.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.14) by necom830.hpcl.titech.ac.jp with SMTP; 22 Jun 2004 21:54:07 -0000 Message-ID: <40D8ABEF.30306@necom830.hpcl.titech.ac.jp> Date: Wed, 23 Jun 2004 07:00:15 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Gert Doering CC: Kurt Erik Lindqvist , address-policy-wg@ripe.net, multi6@ops.ietf.org, Sascha Luck Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> <40D888A1.7070901@necom830.hpcl.titech.ac.jp> <20040622203411.GG6204@Space.Net> In-Reply-To: <20040622203411.GG6204@Space.Net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Gert Doering; >>Note that routers in NLIs may have less performance than those >>in TLIs. > Why? Because with minimum peering global traffic concentrates on peerings between TLIs and because minimum links make the traffice concentrate on backbone links of TLIs. With extra links, extra peerings and associated policies, it is possible to reduce the concentration or even have an NLI link carry more traffic than links of TLIs. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jun 22 17:58:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01366 for ; Tue, 22 Jun 2004 17:58:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BctH6-0006EJ-78 for multi6-data@psg.com; Tue, 22 Jun 2004 21:57:52 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BctH4-0006Du-RW for multi6@ops.ietf.org; Tue, 22 Jun 2004 21:57:51 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5MLvnGm109590 for ; Tue, 22 Jun 2004 21:57:49 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5MLvnMS176286 for ; Tue, 22 Jun 2004 23:57:49 +0200 Received: from zurich.ibm.com (brc.watson.ibm.com [9.2.240.32]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA22438 for ; Tue, 22 Jun 2004 23:57:48 +0200 Message-ID: <40D8AB58.9030708@zurich.ibm.com> Date: Tue, 22 Jun 2004 23:57:44 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: optimum routing table size References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <20040622114911.GK6204@Space.Net> <40D8237D.5020301@necom830.hpcl.titech.ac.jp> <20040622123509.GT6204@Space.Net> <40D8333F.8000804@necom830.hpcl.titech.ac.jp> <40D88C21.6030208@necom830.hpcl.titech.ac.jp> In-Reply-To: <40D88C21.6030208@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I don't think this topic is relevant to the next steps planned for this WG, and it is a very old story that has been discussed often for more than ten years. Brian From owner-multi6@ops.ietf.org Tue Jun 22 18:08:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02417 for ; Tue, 22 Jun 2004 18:08:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BctQh-0007eu-CZ for multi6-data@psg.com; Tue, 22 Jun 2004 22:07:47 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BctQg-0007eM-9C for multi6@ops.ietf.org; Tue, 22 Jun 2004 22:07:46 +0000 Received: (qmail 49036 invoked from network); 22 Jun 2004 22:06:43 -0000 Received: from yahoobb219001188014.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.14) by necom830.hpcl.titech.ac.jp with SMTP; 22 Jun 2004 22:06:43 -0000 Message-ID: <40D8AEE3.6060106@necom830.hpcl.titech.ac.jp> Date: Wed, 23 Jun 2004 07:12:51 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 List Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <6FAEC6CE-C467-11D8-860C-000A95928574@kurtis.pp.se> <40D87CE8.7010909@necom830.hpcl.titech.ac.jp> <40D8AAB1.3040203@zurich.ibm.com> In-Reply-To: <40D8AAB1.3040203@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > > There supposed to be a hard limit on the number of TLAs. > > The concept of TLAs was removed from the IPv6 architecture > quite some time ago. It is it a problem, as discussed in the past meeting. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jun 22 18:21:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03910 for ; Tue, 22 Jun 2004 18:21:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BctdQ-00099c-9N for multi6-data@psg.com; Tue, 22 Jun 2004 22:20:56 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BctdP-00099N-5T for multi6@ops.ietf.org; Tue, 22 Jun 2004 22:20:55 +0000 Received: (qmail 49080 invoked from network); 22 Jun 2004 22:19:52 -0000 Received: from yahoobb219001188014.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.14) by necom830.hpcl.titech.ac.jp with SMTP; 22 Jun 2004 22:19:52 -0000 Message-ID: <40D8B1F7.60506@necom830.hpcl.titech.ac.jp> Date: Wed, 23 Jun 2004 07:25:59 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 Subject: Re: optimum routing table size References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <20040622114911.GK6204@Space.Net> <40D8237D.5020301@necom830.hpcl.titech.ac.jp> <20040622123509.GT6204@Space.Net> <40D8333F.8000804@necom830.hpcl.titech.ac.jp> <40D88C21.6030208@necom830.hpcl.titech.ac.jp> <40D8AB58.9030708@zurich.ibm.com> In-Reply-To: <40D8AB58.9030708@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > I don't think this topic is relevant to the next steps planned > for this WG, and it is a very old story that has been discussed > often for more than ten years. Thank you again for yet another demonstration of poor chairing. The current most "Description of Working Group" in WG homepage, content on which chairs are highly responsible, still says; IPv6 differs from IPv4 in ways that may allow for different approaches to multihoming that are not immediately applicable to IPv4. For example, IPv6 has larger addresses, hosts support multiple addresses per interface, and relatively few IPv6 address blocks have been given out Masataka Ohta From owner-multi6@ops.ietf.org Tue Jun 22 18:31:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04417 for ; Tue, 22 Jun 2004 18:30:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BctmF-000A0I-SR for multi6-data@psg.com; Tue, 22 Jun 2004 22:30:03 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BctmE-0009ze-Jd for multi6@ops.ietf.org; Tue, 22 Jun 2004 22:30:02 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5MM2ZIv031543; Wed, 23 Jun 2004 00:02:35 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <40D88C21.6030208@necom830.hpcl.titech.ac.jp> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <20040622114911.GK6204@Space.Net> <40D8237D.5020301@necom830.hpcl.titech.ac.jp> <20040622123509.GT6204@Space.Net> <40D8333F.8000804@necom830.hpcl.titech.ac.jp> <40D88C21.6030208@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: optimum routing table size Date: Wed, 23 Jun 2004 00:01:03 +0200 To: Masataka Ohta X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka, On 22-jun-04, at 21:44, Masataka Ohta wrote: >> Most routers don't use associative memory or CAMs for routing table >> lookups, this is mostly done for layer 2 switching. > It is because CAM is not large enough for the global routing table. Hm, is there a reason why CAMs can't be made big enough for this? >> Vendors such as Cisco and Juniper use n-way tries for this, which is >> generally quite efficient even for lookups in very large tables. > 1K CAM is very fast. Of course. The trouble with CAMs is that they use a lot of power and run very hot. Regular memory searches are more efficient and usually also fast enough. >> (Note though that looking up routes for the purpose of forwarding is >> not >> the main operational issue with a large routing table, as this scales >> at >> worst at O(log(n)): > Note that the amount of hardware is O(n). Just the memory; most of the other stuff is O(r) where r = number of routers or number of linecards. > Note that it costs more than O(log(n)) times to make already fast > memory O(log(n)) times faster. Certainly. But as long as the increase in bandwidth is equal or lower than the log of the increase in memory speed, we're ok. Relative to the memory speed requirements to read and write packets at a certain bandwidth, the memory speed requirements for looking in the routing table is probably not a big issue. (Although the former may be done using small amounts of expensive memory while storing a very big routing table in such expensive memory isn't much fun for the people who have to pay the bill.) > Note that, with planar layout, there is O(sqrt(n)) factor. What do you mean? >> I don't think CAMs are the right solution, as they are very inflexible > Consider a router on a chip, which is very inflexible, anyway. > A router in a chip is a lot more faster than a router on two chips. Hm, but what problem are we solving here? There are two reasons for having very fast routers: either because you aggregate a lot of traffic, or because you have a lot of traffic going in / coming out of a single place. In the former case speed is only useful if it's affordable: if a 40 Gbps router is 3 times more expensive than 4 10 Gbps routers, ISPs will redesign their networks to use a larger number of smaller routers. In the other case, it may very well be possible to build routers that take advantage of the application scenario. I.e., many packets are going to go in the same direction, so a flow/destination cache based forwarding path would be appropriate here. (Note that this is deadly in an ISP environment where there are many thousands of new flows per second.) >> This way, looking up a route always >> takes one memory cycle, it doesn't get much better than that. >> Obviously >> then the routing table must fit in memory, which means the longest >> prefixes that can be looked up this way are in the order of 26 bits. > Large memory is slow. Note also your comment on BGP convergence. Slow memory is still pretty fast! At 10 Gbps you can do 14.8 million packets per second. With today's RAM it's possible to transfer over 500 MB per second so that compares quite favorably, although this speed is for serial access rather than random access of course. >> In any event, I think putting an artificial limit on the size of the >> routing table is probably more harmful than useful, especially in the >> long run and/or if the limit is quite low such as 8k. > Why do you think 8k quite low? There are already 135k IPv4 routes out there, but more importantly, 30k AS numbers assigned and 15k in use. So at 8k routes half the ASes that are globally visible in v4 today would have "disappear". >> A more fruitful approach would be to look at mechanisms to remove >> unnecessary routing information from routing tables. The obvious way >> to >> do this would be to take advantage of geographic grouping of prefixes >> where possible. > Then, how may route, do you think, is enough? Hard to say. But I really wouldn't want to decide on a fixed number. Rather, I would like the IPv6 internet to "work" with a low number of highly aggregated routes, at least in the core were speed is everything. However, in places where routers can accommodate larger routing tables, it would be beneficial to do controlled deaggregation to take advantage of better optimized paths. I once did some experimenting and if I remember correctly, 75% of traffic used only 10% of all routes. So it might make sense to build a fast core with only 10% of the global routing table in it which can then take care of this 75% of traffic. The remaining traffic can then be tunneled or routed over an auxilary network. On the other hand, if routers can take a full routing table it wouldn't be smart to go through all this hassle. So we need to be flexible. From owner-multi6@ops.ietf.org Tue Jun 22 19:18:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09328 for ; Tue, 22 Jun 2004 19:18:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcuVa-000FBf-6U for multi6-data@psg.com; Tue, 22 Jun 2004 23:16:54 +0000 Received: from [194.15.141.71] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcuVZ-000FBC-2L for multi6@ops.ietf.org; Tue, 22 Jun 2004 23:16:53 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 77DBA474795; Tue, 22 Jun 2004 18:15:58 +0200 (CEST) In-Reply-To: <40D849E2.6010105@necom830.hpcl.titech.ac.jp> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <6FAEC6CE-C467-11D8-860C-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Kurt Erik Lindqvist Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") Date: Tue, 22 Jun 2004 18:15:54 +0200 To: Masataka Ohta X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ohta-san, > Read the draft. Several times today alone, otherwise I wouldn't remember what it said. >> Why would customers go to NLIs in the first place? I for one would >> only >> by service from TLIs. > > It is you who are ignoring the reality. > > Why do customers today buy service from tier2 providers? If we concentrate on the draft-ohta-multihomed-isps-00.txt proposal alone : What you are describing is different service I as a customer would get from my Tier-2/NLI provider. With the model described in draft-ohta-multihomed-isps-00.txt I as a customer would have to change IP addresses if the NLI/Tier-2 provider decided to use another TLI for _their_ commercial reasons. This change will have an economic impact on me as a customer that I would need to recover from my provider, or be prepared to take, without having any influence over how or when this would happen. I, as a customer, would then much rather be a customer of the TLI directly, that would assure me that I would have stable addresses, until _I_ decide to change provider and take the cost of renumbering. This is significantly different from how the Internet works today. If I pick a Tier-2 or Tier-3 provider, I will in most cases get addresses provided out of their PA allocation. That allocation is permanent with the ISP as long as they exist and pays their RIR (and in most cases long after they don't pay their RIR). If I decide to change providers, I change addresses. Again, then it's my decision as a customer that will trigger this. We have very different views on how the Internet operates today and what the underlaying model is. Let's leave it at that. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNhbPaarNKXTPFCVEQK4LQCg4rBkY4PRHF04blhauTuySeVXlRQAn0oq /Y1Jp+kBR9kLOpjR0fMBxDWj =81aQ -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Jun 23 05:22:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10541 for ; Wed, 23 Jun 2004 05:22:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd3vR-0009gJ-WA for multi6-data@psg.com; Wed, 23 Jun 2004 09:20:14 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd3vO-0009fd-Ms for multi6@ops.ietf.org; Wed, 23 Jun 2004 09:20:12 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.1.R) with ESMTP id md50000064389.msg for ; Wed, 23 Jun 2004 11:22:19 +0200 Message-ID: <0a2601c45903$45a98cd0$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <7C5FF932-BE72-11D8-9E53-00039388672E@muada.com> Subject: Re: a/v archive of today's meeting Date: Wed, 23 Jun 2004 11:19:15 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Wed, 23 Jun 2004 11:22:19 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: multi6@ops.ietf.org X-MDAV-Processed: consulintel.es, Wed, 23 Jun 2004 11:22:22 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, We have also made a streaming format of this, available for IPv6 and IPv4, with several options: http://6stream.consulintel.euro6ix.org/multi6_ietf_meeting_14062004_part1.wmv http://6stream.consulintel.euro6ix.org/multi6_ietf_meeting_14062004_part2.wmv http://6stream.consulintel.euro6ix.org/multi6_ietf_meeting_14062004_part3.wmv http://6stream.consulintel.euro6ix.org/multi6_ietf_meeting_14062004_part4.wmv http://6stream.consulintel.euro6ix.org/multi6_ietf_meeting_14062004_part5.wmv or http://6stream.consulintel.euro6ix.org/multi6_ietf_meeting_14062004_part1.htm http://6stream.consulintel.euro6ix.org/multi6_ietf_meeting_14062004_part2.htm http://6stream.consulintel.euro6ix.org/multi6_ietf_meeting_14062004_part3.htm http://6stream.consulintel.euro6ix.org/multi6_ietf_meeting_14062004_part4.htm http://6stream.consulintel.euro6ix.org/multi6_ietf_meeting_14062004_part5.htm or mms://6stream.consulintel.euro6ix.org/multi6_ietf_meeting_santa_monica_part1 mms://6stream.consulintel.euro6ix.org/multi6_ietf_meeting_santa_monica_part2 mms://6stream.consulintel.euro6ix.org/multi6_ietf_meeting_santa_monica_part3 mms://6stream.consulintel.euro6ix.org/multi6_ietf_meeting_santa_monica_part4 mms://6stream.consulintel.euro6ix.org/multi6_ietf_meeting_santa_monica_part5 Regards, Jordi PS: Sorry, I forgot completely about announcing this last week ... ---- Original Message ---- From: "Iljitsch van Beijnum" To: "Multi6" Sent: Tuesday, June 15, 2004 4:19 AM Subject: a/v archive of today's meeting > The recordings of today's meeting are available at: >=20 > http://www.muada.com/multi6streaming2.php >=20 > You can either stream audio+video or download the files if the > streaming doesn't work. The format is Apple Quicktime / MPEG-4. Don't > expect too much from the video, but the audio is good most of the time. >=20 > Let me know if there is any interest in audio-only versions. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-multi6@ops.ietf.org Wed Jun 23 05:47:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11940 for ; Wed, 23 Jun 2004 05:47:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd4L9-000Cbq-FZ for multi6-data@psg.com; Wed, 23 Jun 2004 09:46:47 +0000 Received: from [207.69.200.148] (helo=granger.mail.mindspring.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd4L8-000Cbb-En for multi6@ops.ietf.org; Wed, 23 Jun 2004 09:46:46 +0000 Received: from 1cust143.tnt36.dfw9.da.uu.net ([67.234.81.143] helo=ix.netcom.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1Bd4Ky-00057K-00; Wed, 23 Jun 2004 05:46:36 -0400 Message-ID: <40D96AFD.991B5206@ix.netcom.com> Date: Wed, 23 Jun 2004 04:35:27 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Masataka Ohta CC: Kurt Erik Lindqvist , address-policy-wg@ripe.net, multi6@ops.ietf.org, Gert Doering , Sascha Luck , Brian E Carpenter Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka-sama and all, Open to some does not mean "all the way open" to others. So restrictions for the sake of how far "Open" discussion is, is dependent sometimes on whom is discussing what aspect of relevant issues on a topic area... That said, I liked your draft. I still must study it more however. Masataka Ohta wrote: > Kurt Erik Lindqvist; > > >>Application may use UDP with its own timeout. > > > So all UDP applications need to modified (or not used at multihomed > > sites)? > > If there is a family of UDP applications sharing the same > idea on "connection", there can be a set of connection > management library functions shared by the applications. > Then, it may be that only the library may be modified. > > > This is a discussion that doesn't belong here, but it's not the role of > > the WG chairs to control the WG. > > Then, it was your mistake that you controlled the WG to forbid > presentations of proposals. > > > Make a bidding round for the TLI roles? So you want an open market for > > default-free address space? > > Read the draft for an example. It does not say "open". > > > So Yahoo would qualify as a TLI? If they won a TLI assignment in the > > bidding round? While for example NTT might not? > > Read the draft. > > >>I do recognize the policies and says them orthogonal. > > > Well, the bidding for address space has a large chance to off-set the > > financial models of the Internet today. > > As explained in my presentation, it does not. > > > Why would customers go to NLIs in the first place? I for one would only > > by service from TLIs. > > It is you who are ignoring the reality. > > Why do customers today buy service from tier2 providers? > > Masataka Ohta Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From owner-multi6@ops.ietf.org Wed Jun 23 09:58:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00844 for ; Wed, 23 Jun 2004 09:58:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd8Ew-000L1b-9K for multi6-data@psg.com; Wed, 23 Jun 2004 13:56:38 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd8Eu-000L13-CH for multi6@ops.ietf.org; Wed, 23 Jun 2004 13:56:36 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5NDuZFA112488 for ; Wed, 23 Jun 2004 13:56:35 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5NDuY2t153006 for ; Wed, 23 Jun 2004 15:56:34 +0200 Received: from zurich.ibm.com (brc.watson.ibm.com [9.2.240.32]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA27414 for ; Wed, 23 Jun 2004 15:56:33 +0200 Message-ID: <40D98C0B.6050703@zurich.ibm.com> Date: Wed, 23 Jun 2004 15:56:27 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Message from "Jeff Williams" [Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")] References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <40D96AFD.991B5206@ix.netcom.com> In-Reply-To: <40D96AFD.991B5206@ix.netcom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It's interesting that the person who writes under the pseudonym "Jeff Williams" has start sending his or her usual nonsense to the multi6 list. I advise everybody to not waste their time reading messages from "Jeff Williams", and above *do not* respond, because we know from experience that even more nonsense comes back as a result. Brian Jeff Williams wrote: From owner-multi6@ops.ietf.org Wed Jun 23 10:35:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03016 for ; Wed, 23 Jun 2004 10:35:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd8pj-0000JC-5D for multi6-data@psg.com; Wed, 23 Jun 2004 14:34:39 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd8ph-0000Ib-SI for multi6@ops.ietf.org; Wed, 23 Jun 2004 14:34:38 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5NEYaFA120342 for ; Wed, 23 Jun 2004 14:34:37 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5NEYa07288450 for ; Wed, 23 Jun 2004 16:34:36 +0200 Received: from zurich.ibm.com (brc.watson.ibm.com [9.2.240.32]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA63546 for ; Wed, 23 Jun 2004 16:34:35 +0200 Message-ID: <40D994F6.4020605@zurich.ibm.com> Date: Wed, 23 Jun 2004 16:34:30 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: WG adoption of draft-lear-multi6-things-to-think-about-03.txt References: <40CF2EE2.9030904@zurich.ibm.com> In-Reply-To: <40CF2EE2.9030904@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Since only one objection was received, this draft is now adopted by the WG. Eliot, the next version can be submitted as draft-ietf-multi6-things-to-think-about-00.txt Brian co-chair Brian E Carpenter wrote: > Multi6 people, > > At yesterday's meeting there was strong consensus to adopt > draft-lear-multi6-things-to-think-about-03.txt > as a WG draft. > > If you do not agree with this please say so within a week. > > Brian and Kurtis > > > > From owner-multi6@ops.ietf.org Wed Jun 23 10:36:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03051 for ; Wed, 23 Jun 2004 10:36:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd8qt-0000qg-LN for multi6-data@psg.com; Wed, 23 Jun 2004 14:35:51 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd8qs-0000qG-B5 for multi6@ops.ietf.org; Wed, 23 Jun 2004 14:35:50 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5NEZnGP082464 for ; Wed, 23 Jun 2004 14:35:49 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5NEZm2t176260 for ; Wed, 23 Jun 2004 16:35:48 +0200 Received: from zurich.ibm.com (brc.watson.ibm.com [9.2.240.32]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA63628 for ; Wed, 23 Jun 2004 16:35:47 +0200 Message-ID: <40D9953F.40709@zurich.ibm.com> Date: Wed, 23 Jun 2004 16:35:43 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: WG adoption of draft-nordmark-multi6-threats-01.txt References: <40CF2F1E.9010904@zurich.ibm.com> In-Reply-To: <40CF2F1E.9010904@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Since only one objection was received, this draft is now adopted by the WG. Erik, the next version can be submitted as draft-ietf-multi6-multi6-threats-00.txt Brian co-chair Brian E Carpenter wrote: > Multi6 people, > > At yesterday's meeting there was strong consensus to adopt > draft-nordmark-multi6-threats-01.txt > as a WG draft. > > If you do not agree with this please say so within a week. > > Brian and Kurtis > > > > > > From owner-multi6@ops.ietf.org Wed Jun 23 11:55:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10022 for ; Wed, 23 Jun 2004 11:55:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdA4K-000CQw-0t for multi6-data@psg.com; Wed, 23 Jun 2004 15:53:48 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdA4I-000CQW-Ty for multi6@ops.ietf.org; Wed, 23 Jun 2004 15:53:47 +0000 Received: from isi.edu (lsanca1-ar42-4-61-160-104.lsanca1.dsl-verizon.net [4.61.160.104]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5NFr2J25120; Wed, 23 Jun 2004 08:53:02 -0700 (PDT) Message-ID: <40D9A759.2090105@isi.edu> Date: Wed, 23 Jun 2004 08:52:57 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: multi6@ops.ietf.org Subject: Re: Message from "Jeff Williams" [Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")] References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <40D96AFD.991B5206@ix.netcom.com> <40D98C0B.6050703@zurich.ibm.com> In-Reply-To: <40D98C0B.6050703@zurich.ibm.com> X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7AC1A928B4E6FB2DF47D7448" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-0.6 required=5.0 tests=BAYES_00,RCVD_IN_RFCI, RCVD_IN_SORBS,SUBJ_HAS_SPACES autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7AC1A928B4E6FB2DF47D7448 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Brian, If someone is posting under a pseudonym, please indicate who you believe the real author is and why. As to whether to reply, I would prefer that you let the WG decide that for themselves. Blackballing posters is an extreme measure, and shouldn't be done unless absolutely necessary. Besides, trolls are everywhere. Joe Brian E Carpenter wrote: > It's interesting that the person who writes under the pseudonym > "Jeff Williams" has start sending his or her usual nonsense to > the multi6 list. I advise everybody to not waste their time > reading messages from "Jeff Williams", and above *do not* > respond, because we know from experience that even more > nonsense comes back as a result. > > Brian > > > Jeff Williams wrote: > > --------------enig7AC1A928B4E6FB2DF47D7448 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA2adiE5f5cImnZrsRAkdAAJwPg+57q/TcPlEKJJL+iGQOkBK/FwCgqGcN qUZMHmaX2jZOQ4nnN3v+Su4= =AVNx -----END PGP SIGNATURE----- --------------enig7AC1A928B4E6FB2DF47D7448-- From owner-multi6@ops.ietf.org Wed Jun 23 12:07:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10648 for ; Wed, 23 Jun 2004 12:07:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdAGH-000EyM-Fd for multi6-data@psg.com; Wed, 23 Jun 2004 16:06:09 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdAGF-000Ext-Vu for multi6@ops.ietf.org; Wed, 23 Jun 2004 16:06:08 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.1.R) with ESMTP id md50000065892.msg for ; Wed, 23 Jun 2004 18:08:16 +0200 Message-ID: <14a201c4593b$f8b46150$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <40D96AFD.991B5206@ix.netcom.com> <40D98C0B.6050703@zurich.ibm.com> <40D9A759.2090105@isi.edu> Subject: Re: Message from "Jeff Williams" [Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")] Date: Wed, 23 Jun 2004 18:05:57 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Wed, 23 Jun 2004 18:08:16 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 138.4.0.14 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: multi6@ops.ietf.org X-MDAV-Processed: consulintel.es, Wed, 23 Jun 2004 18:08:20 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Joe, I was "spammed" by "Jeff Williams" in another mailing list during some time, with very strange comments and opinions and only because Brian show me the complete history, I realized I was being cheated. Actually I received a couple of days ago a private email from Jeff (again in response to an email in another mailing list in RIPE), and I just ignored it ;-) Is like another more "Jim Fleming" I guess ... or may be is him with another email account ! Regards, Jordi ----- Original Message -----=20 From: "Joe Touch" To: "Brian E Carpenter" Cc: Sent: Wednesday, June 23, 2004 5:52 PM Subject: Re: Message from "Jeff Williams" [Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")] Brian, If someone is posting under a pseudonym, please indicate who you believe=20 the real author is and why. As to whether to reply, I would prefer that you let the WG decide that=20 for themselves. Blackballing posters is an extreme measure, and=20 shouldn't be done unless absolutely necessary. Besides, trolls are=20 everywhere. Joe Brian E Carpenter wrote: > It's interesting that the person who writes under the pseudonym > "Jeff Williams" has start sending his or her usual nonsense to > the multi6 list. I advise everybody to not waste their time > reading messages from "Jeff Williams", and above *do not* > respond, because we know from experience that even more > nonsense comes back as a result. >=20 > Brian >=20 >=20 > Jeff Williams wrote: >=20 > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-multi6@ops.ietf.org Wed Jun 23 15:26:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08956 for ; Wed, 23 Jun 2004 15:26:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdDM9-000Lbq-3t for multi6-data@psg.com; Wed, 23 Jun 2004 19:24:25 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdDLr-000LXv-4S for multi6@ops.ietf.org; Wed, 23 Jun 2004 19:24:07 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5NJNwGm055440; Wed, 23 Jun 2004 19:23:58 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5NJNw07279084; Wed, 23 Jun 2004 21:23:58 +0200 Received: from zurich.ibm.com (brc.watson.ibm.com [9.2.240.32]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id VAA25974; Wed, 23 Jun 2004 21:23:57 +0200 Message-ID: <40D9D8C7.40604@zurich.ibm.com> Date: Wed, 23 Jun 2004 21:23:51 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Joe Touch CC: multi6@ops.ietf.org Subject: Re: Message from "Jeff Williams" [Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")] References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <40D96AFD.991B5206@ix.netcom.com> <40D98C0B.6050703@zurich.ibm.com> <40D9A759.2090105@isi.edu> In-Reply-To: <40D9A759.2090105@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe, Nobody has ever traced the person behind "Jeff Williams". I'm surprised you haven't come across his or her output before. I make no apology for attempting to prevent him or her wasting our time, as he or she has wasted time of many other IETF WGs in the past. Brian Joe Touch wrote: > Brian, > > If someone is posting under a pseudonym, please indicate who you believe > the real author is and why. > > As to whether to reply, I would prefer that you let the WG decide that > for themselves. Blackballing posters is an extreme measure, and > shouldn't be done unless absolutely necessary. Besides, trolls are > everywhere. > > Joe > > Brian E Carpenter wrote: > >> It's interesting that the person who writes under the pseudonym >> "Jeff Williams" has start sending his or her usual nonsense to >> the multi6 list. I advise everybody to not waste their time >> reading messages from "Jeff Williams", and above *do not* >> respond, because we know from experience that even more >> nonsense comes back as a result. >> >> Brian >> >> >> Jeff Williams wrote: >> >> From owner-multi6@ops.ietf.org Wed Jun 23 16:22:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13605 for ; Wed, 23 Jun 2004 16:22:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdEEC-0004YW-IM for multi6-data@psg.com; Wed, 23 Jun 2004 20:20:16 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdEDw-0004Vh-IQ for multi6@ops.ietf.org; Wed, 23 Jun 2004 20:20:00 +0000 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5NKIiJ05669; Wed, 23 Jun 2004 13:18:44 -0700 (PDT) Message-ID: <40D9E529.4090406@isi.edu> Date: Wed, 23 Jun 2004 13:16:41 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: multi6@ops.ietf.org Subject: Re: Message from "Jeff Williams" [Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")] References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <40D96AFD.991B5206@ix.netcom.com> <40D98C0B.6050703@zurich.ibm.com> <40D9A759.2090105@isi.edu> <40D9D8C7.40604@zurich.ibm.com> In-Reply-To: <40D9D8C7.40604@zurich.ibm.com> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig142BF5171A07CE8337CE6058" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig142BF5171A07CE8337CE6058 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I've come across the posts of many trolls, many of whom waste time. Is there some reason you believe Jeff Williams is more of a pseudonym than any of the other trolls? I.e., if you're going to make that accusation (of pseudonym), please include the reasons for the accusation. Joe Brian E Carpenter wrote: > Joe, > > Nobody has ever traced the person behind "Jeff Williams". I'm > surprised you haven't come across his or her output before. > I make no apology for attempting to prevent him or her > wasting our time, as he or she has wasted time of many other > IETF WGs in the past. > > Brian > > Joe Touch wrote: > >> Brian, >> >> If someone is posting under a pseudonym, please indicate who you >> believe the real author is and why. >> >> As to whether to reply, I would prefer that you let the WG decide that >> for themselves. Blackballing posters is an extreme measure, and >> shouldn't be done unless absolutely necessary. Besides, trolls are >> everywhere. >> >> Joe >> >> Brian E Carpenter wrote: >> >>> It's interesting that the person who writes under the pseudonym >>> "Jeff Williams" has start sending his or her usual nonsense to >>> the multi6 list. I advise everybody to not waste their time >>> reading messages from "Jeff Williams", and above *do not* >>> respond, because we know from experience that even more >>> nonsense comes back as a result. >>> >>> Brian >>> >>> >>> Jeff Williams wrote: >>> >>> --------------enig142BF5171A07CE8337CE6058 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFA2eUtE5f5cImnZrsRAvjJAJ9lDcgS4/OTEzbrsuoO5OpIf2t+ygCg479T tnnv7Wt2DboEa6jgW4yRZHg= =gR6Y -----END PGP SIGNATURE----- --------------enig142BF5171A07CE8337CE6058-- From owner-multi6@ops.ietf.org Wed Jun 23 17:12:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18496 for ; Wed, 23 Jun 2004 17:12:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdF18-000BvU-Lq for multi6-data@psg.com; Wed, 23 Jun 2004 21:10:50 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BdF0u-000Bty-3S for multi6@ops.ietf.org; Wed, 23 Jun 2004 21:10:36 +0000 Received: (qmail 55616 invoked from network); 23 Jun 2004 21:09:49 -0000 Received: from yahoobb219001188014.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.14) by necom830.hpcl.titech.ac.jp with SMTP; 23 Jun 2004 21:09:49 -0000 Message-ID: <40D9F2FD.8070004@necom830.hpcl.titech.ac.jp> Date: Thu, 24 Jun 2004 06:15:41 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Havard Eidnes CC: gert@space.net, kurtis@kurtis.pp.se, address-policy-wg@ripe.net, multi6@ops.ietf.org, ripe-lst@eirconnect.net Subject: Re: [address-policy-wg] Re: Fallacy by Kurt References: <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> <40D888A1.7070901@necom830.hpcl.titech.ac.jp> <20040623.162229.70984010.he@uninett.no> In-Reply-To: <20040623.162229.70984010.he@uninett.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Havard Eidnes wrote: Thank you for good examples. >>>Something that right now confuses *me* is: If I understand this >>>correctly, the 'default-free zone' is meant to be kept below 1000 >>>routes, so routers can be fast. >> >>The hard limit is, IMO, 8192. > Past history has told us that at least some technologists have > failed miserably in predicting whether fast routers can be built > which handle largish routing tables. And, I happened to be a technologist who know how to build a fast (Pbps or more) router even before no one have the needs. So, the only problem on fast routers is their prices. Limiting the number of global routing table entries helps a lot. With no loops in the forwarding path of routers, the limiting factor is latency of routing table look up. While parallelism is a solution, it does not reduce the routing table size. So, to reduce the prices of routers, it is better to reduce the routing table size. Their are poeple who use science to prove that it is impossible to make flying machines. Their are people who use science to make flying machines more efficient and less expensive. > If I recall correctly, an argument similar to the above one was > one of the arguments the ATM proponents used in their day: you > need a short header to do fast lookups, and "fast IP routers > cannot be built". History since then has at least told me that > this was not entirely accurate. At that days, my theory explained why ATM is about 10 times slower than IP. The theory is simply that, given 28 bit address with hierarchy (VPI/VCI or more), it is almost as complex as processing 32 bit IP. So, it takes about 10 times more amount of work to process 48B chunks than 500B-in-average chunks. Of course, there are other factors obscuring the essential difference. > Therefore, I tend to view the above justification and limits with > a healthy dose of scepticism. So, you can still insist that my theory is incorrect and ATM is 8192 or more times faster than IP, while I can keep saying ATM is about 10 times slower than IP with reasons. I can also say 8192 is large enough for the number of global routing table entries with reasons. You can alsy say IPv6 is no good because 128 bit address is not long enough. But, it's your limitation, not mine. Masataka Ohta PS Note that there are people who analize that large routing table increases the time for BGP convergence. From owner-multi6@ops.ietf.org Wed Jun 23 17:47:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20662 for ; Wed, 23 Jun 2004 17:47:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdFYv-000Hp1-FH for multi6-data@psg.com; Wed, 23 Jun 2004 21:45:45 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdFYQ-000Hfv-2c for multi6@ops.ietf.org; Wed, 23 Jun 2004 21:45:14 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5NLj5Gm111836; Wed, 23 Jun 2004 21:45:05 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5NLj52t162178; Wed, 23 Jun 2004 23:45:05 +0200 Received: from zurich.ibm.com (brc.watson.ibm.com [9.2.240.32]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA65338; Wed, 23 Jun 2004 23:45:04 +0200 Message-ID: <40D9F9DB.5040506@zurich.ibm.com> Date: Wed, 23 Jun 2004 23:44:59 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Joe Touch CC: multi6@ops.ietf.org Subject: Re: Message from "Jeff Williams" [Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")] References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <40D96AFD.991B5206@ix.netcom.com> <40D98C0B.6050703@zurich.ibm.com> <40D9A759.2090105@isi.edu> <40D9D8C7.40604@zurich.ibm.com> <40D9E529.4090406@isi.edu> In-Reply-To: <40D9E529.4090406@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe, Try http://www.gtld-mou.org/gtld-discuss/mail-archive/08030.html It's 5 years old; Google might find something more recent if you can be bothered. I can't. Brian Joe Touch wrote: > I've come across the posts of many trolls, many of whom waste time. Is > there some reason you believe Jeff Williams is more of a pseudonym than > any of the other trolls? > > I.e., if you're going to make that accusation (of pseudonym), please > include the reasons for the accusation. > > Joe > > Brian E Carpenter wrote: > >> Joe, >> >> Nobody has ever traced the person behind "Jeff Williams". I'm >> surprised you haven't come across his or her output before. >> I make no apology for attempting to prevent him or her >> wasting our time, as he or she has wasted time of many other >> IETF WGs in the past. >> >> Brian >> >> Joe Touch wrote: >> >>> Brian, >>> >>> If someone is posting under a pseudonym, please indicate who you >>> believe the real author is and why. >>> >>> As to whether to reply, I would prefer that you let the WG decide >>> that for themselves. Blackballing posters is an extreme measure, and >>> shouldn't be done unless absolutely necessary. Besides, trolls are >>> everywhere. >>> >>> Joe >>> >>> Brian E Carpenter wrote: >>> >>>> It's interesting that the person who writes under the pseudonym >>>> "Jeff Williams" has start sending his or her usual nonsense to >>>> the multi6 list. I advise everybody to not waste their time >>>> reading messages from "Jeff Williams", and above *do not* >>>> respond, because we know from experience that even more >>>> nonsense comes back as a result. >>>> >>>> Brian >>>> >>>> >>>> Jeff Williams wrote: >>>> >>>> From owner-multi6@ops.ietf.org Wed Jun 23 17:54:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21090 for ; Wed, 23 Jun 2004 17:54:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdFfv-000JBN-2S for multi6-data@psg.com; Wed, 23 Jun 2004 21:52:59 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdFff-000J7w-5j for multi6@ops.ietf.org; Wed, 23 Jun 2004 21:52:43 +0000 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5NLpZJ27493; Wed, 23 Jun 2004 14:51:35 -0700 (PDT) Message-ID: <40D9FAEC.8050409@isi.edu> Date: Wed, 23 Jun 2004 14:49:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: multi6@ops.ietf.org Subject: Re: Message from "Jeff Williams" [Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")] References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <40D96AFD.991B5206@ix.netcom.com> <40D98C0B.6050703@zurich.ibm.com> <40D9A759.2090105@isi.edu> <40D9D8C7.40604@zurich.ibm.com> <40D9E529.4090406@isi.edu> <40D9F9DB.5040506@zurich.ibm.com> In-Reply-To: <40D9F9DB.5040506@zurich.ibm.com> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6A8D221AFC24B0B3A9FBDA6D" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6A8D221AFC24B0B3A9FBDA6D Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks. That was what I wanted included in the multi6 archives. Joe Brian E Carpenter wrote: > Joe, > > Try http://www.gtld-mou.org/gtld-discuss/mail-archive/08030.html > > It's 5 years old; Google might find something more recent if > you can be bothered. I can't. > > Brian > > Joe Touch wrote: > >> I've come across the posts of many trolls, many of whom waste time. Is >> there some reason you believe Jeff Williams is more of a pseudonym >> than any of the other trolls? >> >> I.e., if you're going to make that accusation (of pseudonym), please >> include the reasons for the accusation. >> >> Joe >> >> Brian E Carpenter wrote: >> >>> Joe, >>> >>> Nobody has ever traced the person behind "Jeff Williams". I'm >>> surprised you haven't come across his or her output before. >>> I make no apology for attempting to prevent him or her >>> wasting our time, as he or she has wasted time of many other >>> IETF WGs in the past. >>> >>> Brian >>> >>> Joe Touch wrote: >>> >>>> Brian, >>>> >>>> If someone is posting under a pseudonym, please indicate who you >>>> believe the real author is and why. >>>> >>>> As to whether to reply, I would prefer that you let the WG decide >>>> that for themselves. Blackballing posters is an extreme measure, and >>>> shouldn't be done unless absolutely necessary. Besides, trolls are >>>> everywhere. >>>> >>>> Joe >>>> >>>> Brian E Carpenter wrote: >>>> >>>>> It's interesting that the person who writes under the pseudonym >>>>> "Jeff Williams" has start sending his or her usual nonsense to >>>>> the multi6 list. I advise everybody to not waste their time >>>>> reading messages from "Jeff Williams", and above *do not* >>>>> respond, because we know from experience that even more >>>>> nonsense comes back as a result. >>>>> >>>>> Brian >>>>> >>>>> >>>>> Jeff Williams wrote: >>>>> >>>>> --------------enig6A8D221AFC24B0B3A9FBDA6D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFA2frwE5f5cImnZrsRApu2AKDMHElAZP/dNI67pU+T0Jjd2fO5bgCg7J7A NUmsXcWt+JpgN+rKiV2CS6k= =DRJK -----END PGP SIGNATURE----- --------------enig6A8D221AFC24B0B3A9FBDA6D-- From owner-multi6@ops.ietf.org Wed Jun 23 18:44:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25309 for ; Wed, 23 Jun 2004 18:44:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdGRc-000PjQ-O1 for multi6-data@psg.com; Wed, 23 Jun 2004 22:42:16 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdGRN-000PhH-BW for multi6@ops.ietf.org; Wed, 23 Jun 2004 22:42:03 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.1.R) with ESMTP id md50000066574.msg for ; Thu, 24 Jun 2004 00:44:10 +0200 Message-ID: <189e01c45973$4b4f3610$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <40D96AFD.991B5206@ix.netcom.com> <40D98C0B.6050703@zurich.ibm.com> <40D9A759.2090105@isi.edu> <40D9D8C7.40604@zurich.ibm.com> <40D9E529.4090406@isi.edu> <40D9F9DB.5040506@zurich.ibm.com> Subject: Re: Message from "Jeff Williams" [Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")] Date: Thu, 24 Jun 2004 00:41:57 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Thu, 24 Jun 2004 00:44:10 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: multi6@ops.ietf.org X-MDAV-Processed: consulintel.es, Thu, 24 Jun 2004 00:44:14 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Someone forwarded me a couple more: http://www.dnso.org/clubpublic/ga/Arc09/msg01569.html http://www.gtld-mou.org/gtld-discuss/mail-archive/08015.html I also found: http://www.fitug.de/icann-europe/0106/msg00018.html http://www.dnso.org/clubpublic/ga-full/Arc00/msg00089.html http://www.dnso.org/clubpublic/ga-full/Arc00/msg00094.html http://www.gtld-mou.org/gtld-discuss/mail-archive/07997.html Regards, Jordi ----- Original Message -----=20 From: "Brian E Carpenter" To: "Joe Touch" Cc: Sent: Wednesday, June 23, 2004 11:44 PM Subject: Re: Message from "Jeff Williams" [Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")] > Joe, >=20 > Try http://www.gtld-mou.org/gtld-discuss/mail-archive/08030.html >=20 > It's 5 years old; Google might find something more recent if > you can be bothered. I can't. >=20 > Brian >=20 > Joe Touch wrote: > > I've come across the posts of many trolls, many of whom waste time. Is=20 > > there some reason you believe Jeff Williams is more of a pseudonym than=20 > > any of the other trolls? > >=20 > > I.e., if you're going to make that accusation (of pseudonym), please=20 > > include the reasons for the accusation. > >=20 > > Joe > >=20 > > Brian E Carpenter wrote: > >=20 > >> Joe, > >> > >> Nobody has ever traced the person behind "Jeff Williams". I'm > >> surprised you haven't come across his or her output before. > >> I make no apology for attempting to prevent him or her > >> wasting our time, as he or she has wasted time of many other > >> IETF WGs in the past. > >> > >> Brian > >> > >> Joe Touch wrote: > >> > >>> Brian, > >>> > >>> If someone is posting under a pseudonym, please indicate who you=20 > >>> believe the real author is and why. > >>> > >>> As to whether to reply, I would prefer that you let the WG decide=20 > >>> that for themselves. Blackballing posters is an extreme measure, and=20 > >>> shouldn't be done unless absolutely necessary. Besides, trolls are=20 > >>> everywhere. > >>> > >>> Joe > >>> > >>> Brian E Carpenter wrote: > >>> > >>>> It's interesting that the person who writes under the pseudonym > >>>> "Jeff Williams" has start sending his or her usual nonsense to > >>>> the multi6 list. I advise everybody to not waste their time > >>>> reading messages from "Jeff Williams", and above *do not* > >>>> respond, because we know from experience that even more > >>>> nonsense comes back as a result. > >>>> > >>>> Brian > >>>> > >>>> > >>>> Jeff Williams wrote: > >>>> > >>>> >=20 >=20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-multi6@ops.ietf.org Wed Jun 23 19:45:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27995 for ; Wed, 23 Jun 2004 19:45:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdHO9-00078O-4D for multi6-data@psg.com; Wed, 23 Jun 2004 23:42:45 +0000 Received: from [207.69.200.226] (helo=blount.mail.mindspring.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdHNn-00073p-HE for multi6@ops.ietf.org; Wed, 23 Jun 2004 23:42:23 +0000 Received: from 1cust57.tnt36.dfw9.da.uu.net ([67.234.81.57] helo=ix.netcom.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BdHNj-0008SK-00; Wed, 23 Jun 2004 19:42:19 -0400 Message-ID: <40DA2EDD.59229989@ix.netcom.com> Date: Wed, 23 Jun 2004 18:31:10 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Brian E Carpenter CC: multi6@ops.ietf.org Subject: Re: Message from "Jeff Williams" [Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")] References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <40D96AFD.991B5206@ix.netcom.com> <40D98C0B.6050703@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_NJABL, RCVD_IN_SORBS,SUBJ_HAS_SPACES autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian and all, Oh sure! You know better Brian... Brian E Carpenter wrote: > It's interesting that the person who writes under the pseudonym > "Jeff Williams" has start sending his or her usual nonsense to > the multi6 list. I advise everybody to not waste their time > reading messages from "Jeff Williams", and above *do not* > respond, because we know from experience that even more > nonsense comes back as a result. > > Brian > > Jeff Williams wrote: > > -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From owner-multi6@ops.ietf.org Wed Jun 23 19:55:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28704 for ; Wed, 23 Jun 2004 19:55:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdHZF-0008qX-3A for multi6-data@psg.com; Wed, 23 Jun 2004 23:54:13 +0000 Received: from [207.69.200.57] (helo=mclean.mail.mindspring.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdHYz-0008nz-MA for multi6@ops.ietf.org; Wed, 23 Jun 2004 23:53:58 +0000 Received: from 1cust57.tnt36.dfw9.da.uu.net ([67.234.81.57] helo=ix.netcom.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BdHYw-0007j0-00; Wed, 23 Jun 2004 19:53:54 -0400 Message-ID: <40DA3194.2BE245F4@ix.netcom.com> Date: Wed, 23 Jun 2004 18:42:44 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Joe Touch CC: Brian E Carpenter , multi6@ops.ietf.org Subject: Re: Message from "Jeff Williams" [Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")] References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <40D96AFD.991B5206@ix.netcom.com> <40D98C0B.6050703@zurich.ibm.com> <40D9A759.2090105@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_NJABL, RCVD_IN_SORBS,SUBJ_HAS_SPACES autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe and all, I'll be brief on this silliness one more time. Brian and I have had some "run-ins" from time to time. I won't necessarily agree with him in areas where I feel, know, or otherwise believe are either incorrect or could be better. Brian has taken offense to how I state my or our organizations ideas or positions. I am sorry he does. We and I have our styles, which it has from time to time seemingly offended Brian, Randy and a few others within the IETF. My own personal opinion is that most of this silliness is borne of ego, rather than sound reasoning, though sound reasoning is, and has been present during several differences of opinion between Brian or Randy and I... Joe Touch wrote: > Brian, > > If someone is posting under a pseudonym, please indicate who you believe > the real author is and why. > > As to whether to reply, I would prefer that you let the WG decide that > for themselves. Blackballing posters is an extreme measure, and > shouldn't be done unless absolutely necessary. Besides, trolls are > everywhere. > > Joe > > Brian E Carpenter wrote: > > > It's interesting that the person who writes under the pseudonym > > "Jeff Williams" has start sending his or her usual nonsense to > > the multi6 list. I advise everybody to not waste their time > > reading messages from "Jeff Williams", and above *do not* > > respond, because we know from experience that even more > > nonsense comes back as a result. > > > > Brian > > > > > > Jeff Williams wrote: > > > > > > ------------------------------------------------------------------------ > > Name: signature.asc > signature.asc Type: application/pgp-signature > Description: OpenPGP digital signature Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From owner-multi6@ops.ietf.org Wed Jun 23 20:11:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29573 for ; Wed, 23 Jun 2004 20:11:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdHoV-000ByI-1Z for multi6-data@psg.com; Thu, 24 Jun 2004 00:09:59 +0000 Received: from [207.69.200.243] (helo=maynard.mail.mindspring.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdHoI-000BwH-Da for multi6@ops.ietf.org; Thu, 24 Jun 2004 00:09:46 +0000 Received: from 1cust57.tnt36.dfw9.da.uu.net ([67.234.81.57] helo=ix.netcom.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BdHoE-0006GR-00; Wed, 23 Jun 2004 20:09:43 -0400 Message-ID: <40DA3548.204FEEDE@ix.netcom.com> Date: Wed, 23 Jun 2004 18:58:32 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Joe Touch CC: Brian E Carpenter , multi6@ops.ietf.org Subject: Re: Message from "Jeff Williams" [Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")] References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <40D96AFD.991B5206@ix.netcom.com> <40D98C0B.6050703@zurich.ibm.com> <40D9A759.2090105@isi.edu> <40D9D8C7.40604@zurich.ibm.com> <40D9E529.4090406@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_NJABL, RCVD_IN_SORBS,SUBJ_HAS_SPACES autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe and all, I am not a pseudonym. See for instance: http://www.ntia.doc.gov/ntiahome/domainname/proposals/ineginc/ineginc.htm So this is just one of Brian's terribly unfortunate methods of attempting to justify his ego, IMHO... Joe Touch wrote: > I've come across the posts of many trolls, many of whom waste time. Is > there some reason you believe Jeff Williams is more of a pseudonym than > any of the other trolls? > > I.e., if you're going to make that accusation (of pseudonym), please > include the reasons for the accusation. > > Joe > > Brian E Carpenter wrote: > > Joe, > > > > Nobody has ever traced the person behind "Jeff Williams". I'm > > surprised you haven't come across his or her output before. > > I make no apology for attempting to prevent him or her > > wasting our time, as he or she has wasted time of many other > > IETF WGs in the past. > > > > Brian > > > > Joe Touch wrote: > > > >> Brian, > >> > >> If someone is posting under a pseudonym, please indicate who you > >> believe the real author is and why. > >> > >> As to whether to reply, I would prefer that you let the WG decide that > >> for themselves. Blackballing posters is an extreme measure, and > >> shouldn't be done unless absolutely necessary. Besides, trolls are > >> everywhere. > >> > >> Joe > >> > >> Brian E Carpenter wrote: > >> > >>> It's interesting that the person who writes under the pseudonym > >>> "Jeff Williams" has start sending his or her usual nonsense to > >>> the multi6 list. I advise everybody to not waste their time > >>> reading messages from "Jeff Williams", and above *do not* > >>> respond, because we know from experience that even more > >>> nonsense comes back as a result. > >>> > >>> Brian > >>> > >>> > >>> Jeff Williams wrote: > >>> > >>> > > ------------------------------------------------------------------------ > > Name: signature.asc > signature.asc Type: application/pgp-signature > Description: OpenPGP digital signature Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From owner-multi6@ops.ietf.org Wed Jun 23 20:25:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00389 for ; Wed, 23 Jun 2004 20:25:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdI2k-000Dgc-5L for multi6-data@psg.com; Thu, 24 Jun 2004 00:24:42 +0000 Received: from [207.69.200.243] (helo=maynard.mail.mindspring.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdI2Y-000DfZ-2R for multi6@ops.ietf.org; Thu, 24 Jun 2004 00:24:30 +0000 Received: from 1cust57.tnt36.dfw9.da.uu.net ([67.234.81.57] helo=ix.netcom.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BdI2X-0001Al-00 for multi6@ops.ietf.org; Wed, 23 Jun 2004 20:24:29 -0400 Message-ID: <40DA38BF.57261B9@ix.netcom.com> Date: Wed, 23 Jun 2004 19:13:19 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: "multi6@ops.ietf.org" Subject: More relevant refrence to ME Jeffrey A. Williams Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-0.3 required=5.0 tests=AWL,BAYES_44,RCVD_IN_NJABL, RCVD_IN_SORBS,TO_ADDRESS_EQ_REAL autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit All, See: http://www.dnso.org/dnso/dnsocomments/comments-whois/Arc03/msg00016.html -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From owner-multi6@ops.ietf.org Thu Jun 24 05:06:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17322 for ; Thu, 24 Jun 2004 05:06:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdQ8S-000MGB-9H for multi6-data@psg.com; Thu, 24 Jun 2004 09:03:08 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdQ8E-000MEP-Hd for multi6@ops.ietf.org; Thu, 24 Jun 2004 09:02:54 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5O92TJ6017566; Thu, 24 Jun 2004 02:02:30 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5O92OQ09240; Thu, 24 Jun 2004 11:02:24 +0200 (MEST) Date: Wed, 23 Jun 2004 16:28:34 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: identity persistence and comparison issues To: marcelo bagnulo braun Cc: Iljitsch van Beijnum , multi6@ops.ietf.org, Joe Touch In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_06_12 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Now, the initiator may not need to have such a stable identifier, since > the initiator does not receive communications. what the initiator needs > is an identifier that is stable during the communication lifetime so, > if the locator change, the identifier is maintained so it is the > communication. I agree in principle, but I'm concerned this is a theoretical observation because I don't think we can build systems that know what the lifetime of the communication is. It is true that in many cases "communication lifetime" = "TCP connection lifetime", but if we build solutions assuming this then they will fail for the cases when the equality doesn't hold; whether the communication consists of UDP traffic, referrals, callbacks, or just multiple TCP connections between the same nodes. One could argue that the application should inform the "stack" about the lifetime of the communication, perhaps by defining some new "open" and "close" APIs, i.e. getting close to defining a session layer. But my gut feel is that this requires more changes to the applications than is warranted. Erik From owner-multi6@ops.ietf.org Thu Jun 24 05:29:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18900 for ; Thu, 24 Jun 2004 05:29:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdQX9-000PKZ-MI for multi6-data@psg.com; Thu, 24 Jun 2004 09:28:39 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdQWw-000PIw-OP for multi6@ops.ietf.org; Thu, 24 Jun 2004 09:28:27 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B58EE39F33; Thu, 24 Jun 2004 11:28:25 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 9DCAC39F25; Thu, 24 Jun 2004 11:28:25 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: multi6@ops.ietf.org, Joe Touch , Iljitsch van Beijnum From: marcelo bagnulo braun Subject: Re: identity persistence and comparison issues Date: Thu, 24 Jun 2004 11:29:15 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 24/06/2004, a las 1:28, Erik Nordmark escribi=F3: >> Now, the initiator may not need to have such a stable identifier,=20 >> since >> the initiator does not receive communications. what the initiator=20 >> needs >> is an identifier that is stable during the communication lifetime so, >> if the locator change, the identifier is maintained so it is the >> communication. > > I agree in principle, but I'm concerned this is a theoretical > observation because I don't think we can build systems that > know what the lifetime of the communication is. > > It is true that in many cases "communication lifetime" =3D "TCP=20 > connection > lifetime", but if we build solutions assuming this then they will > fail for the cases when the equality doesn't hold; whether the > communication consists of UDP traffic, referrals, callbacks, or just > multiple TCP connections between the same nodes. > I agree However, i wonder if this issue is not more general and it is not=20 limited to only ephemeral ids proposals (not considering the refferral and call back cases here) I mean, in any proposal that manages bindings between multiple locators=20= that can be used to reach a single endpoint, you need some state in the=20= endpoints about the binding. This state has to be preserved as long as=20= the communication exists, and some garbage collection mechanism is=20 needed to delete this state after it is used. As you mention, the wedge layer does not have knowledge about the apps=20= still need the binding state, so how do you know when to delete it? For example, how does this work in the hip case? a node A starts a communication with node B, so the node A obtains=20 through the DNS the HITB and the locators of node B Node A then generates a state that maps HITB with the set of locators=20 associated with the node B Now how long this state is preserved in node A? and how does the node A=20= knows when to delete it? I mean, perhaps there is an app that has been quiet for a long time and=20= wants to continue the communication afterwards, what happens if the=20 binding information between the HITB and the locators have been=20 deleted? in HIP this is even more difficult because there is no way to=20= obtain the set of locators from a HIT... I guess that the solution would be to use very long garbage collection=20= times, but as you have mentioned sometime before, this approach may=20 introduce some additional danger and it clearly does not guarantee that=20= all apps will be satisfied am i missing something? Any ideas? regards, marcelo > One could argue that the application should inform the "stack" about > the lifetime of the communication, perhaps by defining some new "open" > and "close" APIs, i.e. getting close to defining a session layer. > But my gut feel is that this requires more changes to the applications > than is warranted. > > Erik > > From owner-multi6@ops.ietf.org Thu Jun 24 06:46:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23890 for ; Thu, 24 Jun 2004 06:46:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdRj9-0007Yb-Ct for multi6-data@psg.com; Thu, 24 Jun 2004 10:45:07 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdRix-0007WQ-Kf for multi6@ops.ietf.org; Thu, 24 Jun 2004 10:44:55 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5OAkO2r069482; Thu, 24 Jun 2004 12:46:24 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <88E2EBF4-C5CB-11D8-A349-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: identity persistence and comparison issues Date: Thu, 24 Jun 2004 12:44:57 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 24-jun-04, at 1:28, Erik Nordmark wrote: > One could argue that the application should inform the "stack" about > the lifetime of the communication, perhaps by defining some new "open" > and "close" APIs, i.e. getting close to defining a session layer. > But my gut feel is that this requires more changes to the applications > than is warranted. Hm, I think you're overlooking the fact that in any case where referrals happen, the host that's being referred to must accept incoming connections. An application waiting for incoming connections is something that's pretty easy to detect for a host stack... In other words, the bind(2) call can trigger the creation of a longer-lived identifier. Still, I'm not sure how applications determine which address to use in referrals, it may be necessary to make this an explicit API call = application changes = a bad thing. From owner-multi6@ops.ietf.org Thu Jun 24 10:05:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14404 for ; Thu, 24 Jun 2004 10:05:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdUnC-0004wv-MH for multi6-data@psg.com; Thu, 24 Jun 2004 14:01:30 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BdUn1-0004vU-RH for multi6@ops.ietf.org; Thu, 24 Jun 2004 14:01:20 +0000 Received: (qmail 60370 invoked from network); 24 Jun 2004 14:00:46 -0000 Received: from yahoobb219001188048.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.48) by necom830.hpcl.titech.ac.jp with SMTP; 24 Jun 2004 14:00:46 -0000 Message-ID: <40DADFE3.30004@necom830.hpcl.titech.ac.jp> Date: Thu, 24 Jun 2004 23:06:27 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Jeff Williams CC: Kurt Erik Lindqvist , address-policy-wg@ripe.net, multi6@ops.ietf.org, Gert Doering , Sascha Luck , Brian E Carpenter Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <40D96AFD.991B5206@ix.netcom.com> In-Reply-To: <40D96AFD.991B5206@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DSBL, RCVD_IN_NJABL,RCVD_IN_NJABL_PROXY,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jeff Williams wrote: > Open to some does not mean "all the way open" to others. So restrictions > for the sake of how far "Open" discussion is, is dependent sometimes on > whom is discussing what aspect of relevant issues on a topic area... So true. > That said, I liked your draft. I still must study it more however. Thank you. However, such statement without technical reasoning is no better than the emotional postings by Brian Carpenter. So, let's have discussions on technical points with verifiable reasons. Note, for example, that I oppose any proposal trying to import *THE* swamp of v4. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jun 24 10:12:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15374 for ; Thu, 24 Jun 2004 10:12:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdUw4-0006FO-BI for multi6-data@psg.com; Thu, 24 Jun 2004 14:10:40 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BdUvl-0006Ce-Kh for multi6@ops.ietf.org; Thu, 24 Jun 2004 14:10:21 +0000 Received: (qmail 60430 invoked from network); 24 Jun 2004 14:09:48 -0000 Received: from yahoobb219001188048.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.48) by necom830.hpcl.titech.ac.jp with SMTP; 24 Jun 2004 14:09:48 -0000 Message-ID: <40DAE201.3030905@necom830.hpcl.titech.ac.jp> Date: Thu, 24 Jun 2004 23:15:29 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: marcelo bagnulo braun CC: Erik Nordmark , multi6@ops.ietf.org, Joe Touch , Iljitsch van Beijnum Subject: Re: identity persistence and comparison issues References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DSBL, RCVD_IN_NJABL,RCVD_IN_NJABL_PROXY,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo braun; > I mean, in any proposal that manages bindings between multiple locators > that can be used to reach a single endpoint, you need some state in the > endpoints about the binding. This state has to be preserved as long as > the communication exists, and some garbage collection mechanism is > needed to delete this state after it is used. > As you mention, the wedge layer does not have knowledge about the apps > still need the binding state, so how do you know when to delete it? Just say NAT. > For example, Of course, there are many cases where NAT-like approaches just does not work. A notable example is (v4)FTP. > how does this work in the hip case? It has nothing to do with hip and it does not work. > Now how long this state is preserved in node A? and how does the node A > knows when to delete it? A NAT operator can give you the answer that it is 5 minutes. > I mean, perhaps there is an app that has been quiet for a long time and > wants to continue the communication afterwards, and the reality of the Internet is ignored by people promoting NAT. > I guess that the solution would be to use very long garbage collection > times, but as you have mentioned sometime before, this approach may > introduce some additional danger and it clearly does not guarantee that > all apps will be satisfied > > am i missing something? No, not at all. > Any ideas? We need yet another WG or a standardization body. Masataka Ohta PS If you still believe in IETF, try to argue against me in v6 ML on my reasoning about why ND over WLAN is useless. From owner-multi6@ops.ietf.org Thu Jun 24 10:17:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16133 for ; Thu, 24 Jun 2004 10:17:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdV0v-000751-4I for multi6-data@psg.com; Thu, 24 Jun 2004 14:15:41 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BdV0a-0006zp-EK for multi6@ops.ietf.org; Thu, 24 Jun 2004 14:15:20 +0000 Received: (qmail 60477 invoked from network); 24 Jun 2004 14:14:47 -0000 Received: from yahoobb219001188048.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.48) by necom830.hpcl.titech.ac.jp with SMTP; 24 Jun 2004 14:14:47 -0000 Message-ID: <40DAE32C.9040501@necom830.hpcl.titech.ac.jp> Date: Thu, 24 Jun 2004 23:20:28 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Erik Nordmark , Multi6 Subject: Re: identity persistence and comparison issues References: <88E2EBF4-C5CB-11D8-A349-000A95CD987A@muada.com> In-Reply-To: <88E2EBF4-C5CB-11D8-A349-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DSBL, RCVD_IN_NJABL,RCVD_IN_NJABL_PROXY,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 24-jun-04, at 1:28, Erik Nordmark wrote: > >> One could argue that the application should inform the "stack" about >> the lifetime of the communication, perhaps by defining some new "open" >> and "close" APIs, i.e. getting close to defining a session layer. >> But my gut feel is that this requires more changes to the applications >> than is warranted. > > > Hm, I think you're overlooking the fact that in any case where referrals In short, end systems can not be transparent to address (locator) rewritings. I guess that most people in the last interim meeting are so stupid thay they couldn't have any chance to notice such a basic fact. However, I'm still waiting fof the meeting minutes, even draft ones, to confirm it was really so. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jun 24 11:06:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20102 for ; Thu, 24 Jun 2004 11:06:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdVmN-000Dfi-Rr for multi6-data@psg.com; Thu, 24 Jun 2004 15:04:43 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdVm5-000Dc8-87 for multi6@ops.ietf.org; Thu, 24 Jun 2004 15:04:25 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5OF4IgB100468; Thu, 24 Jun 2004 15:04:18 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5OF4HD9169382; Thu, 24 Jun 2004 17:04:18 +0200 Received: from zurich.ibm.com (brc-009058046173.somers.ibm.com [9.58.46.173]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA35154; Thu, 24 Jun 2004 17:04:16 +0200 Message-ID: <40DADA37.4080800@zurich.ibm.com> Date: Thu, 24 Jun 2004 15:42:15 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Erik Nordmark , Multi6 Subject: Re: identity persistence and comparison issues References: <88E2EBF4-C5CB-11D8-A349-000A95CD987A@muada.com> In-Reply-To: <88E2EBF4-C5CB-11D8-A349-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 24-jun-04, at 1:28, Erik Nordmark wrote: > >> One could argue that the application should inform the "stack" about >> the lifetime of the communication, perhaps by defining some new "open" >> and "close" APIs, i.e. getting close to defining a session layer. >> But my gut feel is that this requires more changes to the applications >> than is warranted. > > > Hm, I think you're overlooking the fact that in any case where referrals > happen, the host that's being referred to must accept incoming > connections. An application waiting for incoming connections is > something that's pretty easy to detect for a host stack... > > In other words, the bind(2) call can trigger the creation of a > longer-lived identifier. Still, I'm not sure how applications determine > which address to use in referrals, it may be necessary to make this an > explicit API call = application changes = a bad thing. That's an interesting point. In a 2-way conversation, a 'close' on a socket is a strong signal that the stack can forget any state (unless there is some optimization possible by caching the state). In a referral conversation that is no longer true - but presumably the referred ID cannot be ephemeral anyway. Or to say it another way, referrals will only be possible with long-life IDs. To avoid *any* apps changes, those long-life IDs are going to have to look exactly like IP addresses, IMHO. Brian (not in the chair at this moment) From owner-multi6@ops.ietf.org Thu Jun 24 11:36:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21861 for ; Thu, 24 Jun 2004 11:36:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdWFH-000HkL-El for multi6-data@psg.com; Thu, 24 Jun 2004 15:34:35 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdWEx-000HhP-6P for multi6@ops.ietf.org; Thu, 24 Jun 2004 15:34:15 +0000 Received: from isi.edu (lsanca1-ar42-4-61-160-104.lsanca1.dsl-verizon.net [4.61.160.104]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5OFWbJ17537; Thu, 24 Jun 2004 08:32:37 -0700 (PDT) Message-ID: <40DAF41A.7090406@isi.edu> Date: Thu, 24 Jun 2004 08:32:42 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Iljitsch van Beijnum , Erik Nordmark , Multi6 Subject: Re: identity persistence and comparison issues References: <88E2EBF4-C5CB-11D8-A349-000A95CD987A@muada.com> <40DADA37.4080800@zurich.ibm.com> In-Reply-To: <40DADA37.4080800@zurich.ibm.com> X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4AFDEE6F9FE3CC5F6EDCF007" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_RFCI, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4AFDEE6F9FE3CC5F6EDCF007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > Iljitsch van Beijnum wrote: > ... >> In other words, the bind(2) call can trigger the creation of a >> longer-lived identifier. Still, I'm not sure how applications >> determine which address to use in referrals, it may be necessary to >> make this an explicit API call = application changes = a bad thing. > > > That's an interesting point. In a 2-way conversation, a 'close' on a socket > is a strong signal that the stack can forget any state (unless there is > some optimization possible by caching the state).... 'close' is an app-side input to the stack; there are other considerations about when to drop state. E.g., TCP has to keep TIME_WAIT to avoid reusing ports/seq numbers. At which point addresses from elsewhere cannot be moved 'here' until these timers expire. Joe --------------enig4AFDEE6F9FE3CC5F6EDCF007 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA2vQaE5f5cImnZrsRAu7LAJ9Tx/WfpN+KWYM4n5QYYJssSr0j5gCg50GG Oz/uo80Rfa24w2JfpOmTq5U= =hpt4 -----END PGP SIGNATURE----- --------------enig4AFDEE6F9FE3CC5F6EDCF007-- From owner-multi6@ops.ietf.org Thu Jun 24 11:55:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23052 for ; Thu, 24 Jun 2004 11:55:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdWXb-000K9E-Vi for multi6-data@psg.com; Thu, 24 Jun 2004 15:53:31 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdWWd-000Jzi-T0 for multi6@ops.ietf.org; Thu, 24 Jun 2004 15:52:32 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F39152A03E for ; Thu, 24 Jun 2004 17:52:30 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp03.uc3m.es (Postfix) with ESMTP id DE1CE2A01E for ; Thu, 24 Jun 2004 17:52:30 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <9E2C48E6-C5F6-11D8-97AE-000D93ACD0FE@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Multi6 List From: marcelo bagnulo braun Subject: about Wedgelayer 3.5 / Fat IP approaches Date: Thu, 24 Jun 2004 17:53:21 +0200 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Among the multiple approaches that have been included within the Wedgelayer 3.5 / Fat IP class, we can find very different mechanisms imho. I I think that additional discussion is needed to understand which one of the different approaches (not particular solution, but general approach) would better fulfill our needs. the goal of this message is then, to provide my opinion of some of the benefits and limitations of each approach in order to foster discussion of this topic. So, as is see it the approaches included within the Wedgelayer 3.5 / Fat IP class use the following types of ULP identifiers: - 128 bit long CBIDs (HIP, SIM) - CGAs (cb64) - Locators (i.e. the use a locators as the ULP id) (NOID, ODT) - ephemeral ids (WIMP, MAST?) Each approach use different mechanisms to prove identifier ownership: - 128 CBID and CGAs use the crypto nature of the id to prove it - When using locators as ids, there seems to me that there are two proposals: - a reachability test i.e. exchanging cookies . imho this approach is not good enough, since in order to prevent time shifted attacks, you need to exchange cookies periodically, which is opposed to the fault tolerance requirement - a third trusted party (i.e. the DNS) which informs about the locators assigned to and identifier, meaning that the endpoint that is reachable at the given locator(s) is the owner of the identifier - when using ephemeral ids, the requirement to prove id ownership is weaker, and only a mechanism to verify that the same endpoint is at different locators is needed. This can be achieved using different crypto mechanisms and pbk and hash chains are proposed. However, only the initiator can use ephemeral ids, in the case of the receiver, a third trusted party (i.e. the dns) is used to link the id and the locator, so that the initiator knows that the endpoint reachable at these locators is the owner of the id In addition different approaches use different mechanisms to verify that an endpoint is authorized to use a given locator: - 128 CBID, CGAs use a reachability test i.e. verifying through a challenge response mechanism that the identifier owner is reachable at the claimed locator - the locator approach use a third trusted party (i.e. the DNS) to discover which locators are bound to an identifier - The ephemeral id approach uses both mechanisms described above Each solution imposes different amount of additional cost to a communication. I guess that the cost can be measured with respect to the following parameters: processing, overhead - 128 CBID, CGAs and ephemeral ids impose different degree of crypto which requires processing by the end nodes. Locator based need no crypto so no additional cost is imposed. However, i kind of agree that it can be assumed that the required crypto operations will be performed rarely, so probably this cost is acceptable. - All proposals require additional packet exchange and while i have not yet compiled the amount of packets required per each proposal, i kind of recall that most proposals impose more or less the same amount of additional packets (i really not sure about this, so i would really appreciate if someone could correct me here) A tricky issue that has appeared repeatedly during last discussion would be the referrals and call back support - 128 CBID and ephemeral ids approaches don't seem to provide a proper support for referrals and call backs, since is not possible to obtain an locator set from the id - locator based and CGAs will use a "valid" locator as an id, so this locator can be used when making referrals. IMHO, this is as good as it is possible to get. I mean, a mh capable node can pass a referral to a non mh capable node. In this case, the non mh capable node only can handle a single locator, so no need to have multiple ones (well, perhaps having one that certainly works could help). If the node that receives the referral is also mh capable, it can use a mapping service (like the reverse DNS) to obtain the rest of the locators. Both CGas and locator based approach could provide such support, i guess Finally, imho an important aspect is the applicability scope of the proposed solution. imho approaches that introduce a new crypto based identifier namespace (128 CBID, cgas) have an applicability scope that is broader that just multihoming, since they can be used to support mobility, and imho they are providing useful tools to achieve a more secure internet. OTOH, the other solutions are basically focused on the multihoming problem and their applicability scope is limited to multihoming ( i can't see other aspects of the Internet that could be improved by the adoption of such solutions) Regards, marcelo From owner-multi6@ops.ietf.org Thu Jun 24 16:31:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26654 for ; Thu, 24 Jun 2004 16:31:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdaoH-0006PB-V5 for multi6-data@psg.com; Thu, 24 Jun 2004 20:27:01 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bdao0-0006N9-J9 for multi6@ops.ietf.org; Thu, 24 Jun 2004 20:26:45 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5OKQRGP055812; Thu, 24 Jun 2004 20:26:27 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5OKQQwQ273534; Thu, 24 Jun 2004 22:26:27 +0200 Received: from zurich.ibm.com (brc.somers.ibm.com [9.58.34.144]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA76882; Thu, 24 Jun 2004 22:26:25 +0200 Message-ID: <40DB38EB.9000400@zurich.ibm.com> Date: Thu, 24 Jun 2004 22:26:19 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Joe Touch CC: Iljitsch van Beijnum , Erik Nordmark , Multi6 Subject: Re: identity persistence and comparison issues References: <88E2EBF4-C5CB-11D8-A349-000A95CD987A@muada.com> <40DADA37.4080800@zurich.ibm.com> <40DAF41A.7090406@isi.edu> In-Reply-To: <40DAF41A.7090406@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe Touch wrote: > > > Brian E Carpenter wrote: > >> Iljitsch van Beijnum wrote: >> > ... > >>> In other words, the bind(2) call can trigger the creation of a >>> longer-lived identifier. Still, I'm not sure how applications >>> determine which address to use in referrals, it may be necessary to >>> make this an explicit API call = application changes = a bad thing. >> >> >> >> That's an interesting point. In a 2-way conversation, a 'close' on a >> socket >> is a strong signal that the stack can forget any state (unless there is >> some optimization possible by caching the state).... > > > 'close' is an app-side input to the stack; there are other > considerations about when to drop state. > > E.g., TCP has to keep TIME_WAIT to avoid reusing ports/seq numbers. At > which point addresses from elsewhere cannot be moved 'here' until these > timers expire. Correct, of course. As usual I abbreviated... but in the absence of the clean up by a transport protocol, i.e. for UDP, the 'close' is all you have. Brian From owner-multi6@ops.ietf.org Thu Jun 24 20:44:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09283 for ; Thu, 24 Jun 2004 20:44:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdenA-000EQo-BY for multi6-data@psg.com; Fri, 25 Jun 2004 00:42:08 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bdemw-000EPE-0T for multi6@ops.ietf.org; Fri, 25 Jun 2004 00:41:54 +0000 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5P0fMJ05231; Thu, 24 Jun 2004 17:41:22 -0700 (PDT) Message-ID: <40DB743C.8060005@isi.edu> Date: Thu, 24 Jun 2004 17:39:24 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: marcelo bagnulo braun , Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: identity persistence and comparison issues References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig924E957A0C4AA38D63D39931" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig924E957A0C4AA38D63D39931 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>Now, the initiator may not need to have such a stable identifier, since >>the initiator does not receive communications. what the initiator needs >>is an identifier that is stable during the communication lifetime so, >>if the locator change, the identifier is maintained so it is the >>communication. > > I agree in principle, but I'm concerned this is a theoretical > observation because I don't think we can build systems that > know what the lifetime of the communication is. We do know. The lifetime is unlimited. A TCP connection can stay up as long as the two endpoints stay up. The identifier needs to be stable at the endpoints as long as the endpoints care - which is why I like how HIP negotiates these labels, and maintains the mapping at the endpoints. The endpoints are the only place that can or should know about whether they change. Joe --------------enig924E957A0C4AA38D63D39931 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFA23Q8E5f5cImnZrsRAiu+AJ4wkuKjUX1XXPHRWmfBAkCKr/csywCgio0Z xJRWV/eXJQkFytF/5fkqsXU= =8NrA -----END PGP SIGNATURE----- --------------enig924E957A0C4AA38D63D39931-- From owner-multi6@ops.ietf.org Thu Jun 24 22:30:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15138 for ; Thu, 24 Jun 2004 22:30:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdgRl-0000nF-9d for multi6-data@psg.com; Fri, 25 Jun 2004 02:28:09 +0000 Received: from [207.69.200.25] (helo=barry.mail.mindspring.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdgRJ-0000jE-CD for multi6@ops.ietf.org; Fri, 25 Jun 2004 02:27:42 +0000 Received: from 1cust164.tnt36.dfw9.da.uu.net ([67.234.81.164] helo=ix.netcom.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BdgR6-0006wA-00; Thu, 24 Jun 2004 22:27:32 -0400 Message-ID: <40DBA70B.BBCD5D4C@ix.netcom.com> Date: Thu, 24 Jun 2004 21:16:13 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Masataka Ohta CC: Kurt Erik Lindqvist , address-policy-wg@ripe.net, "multi6@ops.ietf.org" , Gert Doering , Brian E Carpenter Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <40D96AFD.991B5206@ix.netcom.com> <40DADFE3.30004@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_NJABL, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka-sama and all, Masataka Ohta wrote: > Jeff Williams wrote: > > > Open to some does not mean "all the way open" to others. So restrictions > > for the sake of how far "Open" discussion is, is dependent sometimes on > > whom is discussing what aspect of relevant issues on a topic area... > > So true. > > > That said, I liked your draft. I still must study it more however. > > Thank you. Your welcome, but also you earned it. > > > However, such statement without technical reasoning is no better > than the emotional postings by Brian Carpenter. Understood to a degree. My comment was also meant to be in reference to already discussed by others, your draft, including the already stated technical reasoning and disagreement... > > > So, let's have discussions on technical points with verifiable > reasons. > > Note, for example, that I oppose any proposal trying to import > *THE* swamp of v4. I also. v6 is a very different technically, animal than v4. I am however not a fan of v6 vs v8. But that is another discussion all together. > > > Masataka Ohta Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From owner-multi6@ops.ietf.org Fri Jun 25 04:41:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17357 for ; Fri, 25 Jun 2004 04:41:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdmEj-000HnQ-K0 for multi6-data@psg.com; Fri, 25 Jun 2004 08:39:05 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdmEY-000HlE-3U for multi6@ops.ietf.org; Fri, 25 Jun 2004 08:38:54 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E5DC02A076; Fri, 25 Jun 2004 10:38:52 +0200 (CEST) Received: from [163.117.139.241] (unknown [163.117.139.241]) by smtp03.uc3m.es (Postfix) with ESMTP id C96192A02C; Fri, 25 Jun 2004 10:38:52 +0200 (CEST) In-Reply-To: <40DB743C.8060005@isi.edu> References: <40DB743C.8060005@isi.edu> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <34CB9FE4-C683-11D8-97AE-000D93ACD0FE@ing.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Erik Nordmark , multi6@ops.ietf.org, Iljitsch van Beijnum From: marcelo bagnulo braun Subject: Re: identity persistence and comparison issues Date: Fri, 25 Jun 2004 10:39:43 +0200 To: Joe Touch X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Joe, El 25/06/2004, a las 2:39, Joe Touch escribi=F3: > We do know. The lifetime is unlimited. A TCP connection can stay up as=20= > long as the two endpoints stay up. > > The identifier needs to be stable at the endpoints as long as the=20 > endpoints care - which is why I like how HIP negotiates these labels,=20= > and maintains the mapping at the endpoints. Yes, but for how long does the hip endpoint maintains the mapping=20 between the HIT and the locators of the other endpoints? I mean, there must be a garbage collection mechanism, if not the hip=20 endpoint will have to store infromation about all the endpoints that it=20= has communicated with in the past regards, marcelo > The endpoints are the only place that can or should know about=20 > whether they change. > > Joe > From owner-multi6@ops.ietf.org Fri Jun 25 15:51:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06876 for ; Fri, 25 Jun 2004 15:51:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bdwgf-000GO7-Rb for multi6-data@psg.com; Fri, 25 Jun 2004 19:48:37 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bdwft-000GGc-Mj for multi6@ops.ietf.org; Fri, 25 Jun 2004 19:47:51 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5PJMKgB065242; Fri, 25 Jun 2004 19:22:20 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5PJMJCi164594; Fri, 25 Jun 2004 21:22:19 +0200 Received: from zurich.ibm.com (sig-9-145-171-55.de.ibm.com [9.145.171.55]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id VAA55196; Fri, 25 Jun 2004 21:22:15 +0200 Message-ID: <40DC5165.4070900@zurich.ibm.com> Date: Fri, 25 Jun 2004 18:23:01 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: marcelo bagnulo braun CC: Joe Touch , Erik Nordmark , multi6@ops.ietf.org, Iljitsch van Beijnum Subject: Re: identity persistence and comparison issues References: <40DB743C.8060005@isi.edu> <34CB9FE4-C683-11D8-97AE-000D93ACD0FE@ing.uc3m.es> In-Reply-To: <34CB9FE4-C683-11D8-97AE-000D93ACD0FE@ing.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit marcelo bagnulo braun wrote: > Hi Joe, > > El 25/06/2004, a las 2:39, Joe Touch escribió: > >> We do know. The lifetime is unlimited. A TCP connection can stay up as >> long as the two endpoints stay up. >> >> The identifier needs to be stable at the endpoints as long as the >> endpoints care - which is why I like how HIP negotiates these labels, >> and maintains the mapping at the endpoints. > > > Yes, but for how long does the hip endpoint maintains the mapping > between the HIT and the locators of the other endpoints? > > I mean, there must be a garbage collection mechanism, if not the hip > endpoint will have to store infromation about all the endpoints that it > has communicated with in the past > > regards, marcelo > >> The endpoints are the only place that can or should know about >> whether they change. This is a purist view of the Internet we used to have when RFC 1958 was written... the current reality (RFC 2775) is that all these problems call for soft state solutions, that can be garbage collected as Marcelo says, and recreated if they are prematurely lost. (The tragedy of NATs is that they can't do the second bit reliably, and multi6 needs to avoid that problem.) Brian From owner-multi6@ops.ietf.org Fri Jun 25 22:02:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28991 for ; Fri, 25 Jun 2004 22:02:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Be2UI-000CcC-Fk for multi6-data@psg.com; Sat, 26 Jun 2004 02:00:14 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Be2U9-000Cas-AM for multi6@ops.ietf.org; Sat, 26 Jun 2004 02:00:05 +0000 Received: from [192.168.123.144] (lsanca1-ar42-4-61-160-104.lsanca1.dsl-verizon.net [4.61.160.104]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5Q1wpJ12514; Fri, 25 Jun 2004 18:58:51 -0700 (PDT) Message-ID: <40DCD854.1020904@isi.edu> Date: Fri, 25 Jun 2004 18:58:44 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: marcelo bagnulo braun , Erik Nordmark , multi6@ops.ietf.org, Iljitsch van Beijnum Subject: Re: identity persistence and comparison issues References: <40DB743C.8060005@isi.edu> <34CB9FE4-C683-11D8-97AE-000D93ACD0FE@ing.uc3m.es> <40DC5165.4070900@zurich.ibm.com> In-Reply-To: <40DC5165.4070900@zurich.ibm.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB82F989FB61B62DB70DF79A6" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_RFCI, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB82F989FB61B62DB70DF79A6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > marcelo bagnulo braun wrote: ... >>> The endpoints are the only place that can or should know about >>> whether they change. > > This is a purist view of the Internet we used to have when RFC 1958 > was written... the current reality (RFC 2775) is that all these > problems call for soft state solutions, that can be garbage collected > as Marcelo says, and recreated if they are prematurely lost. Soft state elsewhere is an optimization that relies on hard state at the endpoints for its recovery and recreation anyway. I.e., I don't see yours and Marcelo's views as inconsistent. > (The tragedy of NATs is that they can't do the second bit reliably, > and multi6 needs to avoid that problem.) > > Brian --------------enigB82F989FB61B62DB70DF79A6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA3NhaE5f5cImnZrsRAm+oAKCEbVhmKaP5CDwvV7AmvSrJAy33tACgks34 IPdlOcIweJ3iKc6sPdZb9tI= =D6m7 -----END PGP SIGNATURE----- --------------enigB82F989FB61B62DB70DF79A6-- From owner-multi6@ops.ietf.org Sat Jun 26 06:26:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01273 for ; Sat, 26 Jun 2004 06:26:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BeALr-000JVt-O0 for multi6-data@psg.com; Sat, 26 Jun 2004 10:24:03 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BeALp-000JVE-44 for multi6@ops.ietf.org; Sat, 26 Jun 2004 10:24:01 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AFB7D39E2D; Sat, 26 Jun 2004 12:23:59 +0200 (CEST) Received: from [163.117.252.40] (unknown [163.117.252.40]) by smtp01.uc3m.es (Postfix) with ESMTP id A063239E23; Sat, 26 Jun 2004 12:23:57 +0200 (CEST) In-Reply-To: <40DCD854.1020904@isi.edu> References: <40DB743C.8060005@isi.edu> <34CB9FE4-C683-11D8-97AE-000D93ACD0FE@ing.uc3m.es> <40DC5165.4070900@zurich.ibm.com> <40DCD854.1020904@isi.edu> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <0D578C32-C75B-11D8-97AE-000D93ACD0FE@ing.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Erik Nordmark , multi6@ops.ietf.org, Brian E Carpenter , Iljitsch van Beijnum From: marcelo bagnulo braun Subject: Re: identity persistence and comparison issues Date: Sat, 26 Jun 2004 12:24:48 +0200 To: Joe Touch X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 26/06/2004, a las 3:58, Joe Touch escribi=F3: > > > Brian E Carpenter wrote: > >> marcelo bagnulo braun wrote: > ... >>>> The endpoints are the only place that can or should know about=20 >>>> whether they change. >> This is a purist view of the Internet we used to have when RFC 1958 >> was written... the current reality (RFC 2775) is that all these >> problems call for soft state solutions, that can be garbage collected >> as Marcelo says, and recreated if they are prematurely lost. > > Soft state elsewhere is an optimization that relies on hard state at=20= > the endpoints for its recovery and recreation anyway. I.e., I don't=20 > see yours and Marcelo's views as inconsistent. > One problem is that if the endpoints are incapable of obtaining the=20 locators associated with a given identifier (as in HIP), it is=20 impossible for the endpoints to recover the lost state, so perhaps=20 having a mechanism for mapping id to locators is a must? regards, marcelo >> (The tragedy of NATs is that they can't do the second bit reliably, >> and multi6 needs to avoid that problem.) >> Brian From owner-multi6@ops.ietf.org Sun Jun 27 00:04:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15011 for ; Sun, 27 Jun 2004 00:04:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BeQq7-0001CB-N5 for multi6-data@psg.com; Sun, 27 Jun 2004 04:00:23 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BeQq4-0001B3-Tx for multi6@ops.ietf.org; Sun, 27 Jun 2004 04:00:21 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 22B7612A for ; Sun, 27 Jun 2004 00:00:20 -0400 (EDT) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 27 Jun 2004 00:00:20 -0400 Message-Id: <20040627040020.22B7612A@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 29.17% | 21 | 27.73% | 78849 | mohta@necom830.hpcl.titech.ac.jp 16.67% | 12 | 14.92% | 42431 | brc@zurich.ibm.com 13.89% | 10 | 13.33% | 37900 | kurtis@kurtis.pp.se 9.72% | 7 | 10.64% | 30255 | touch@isi.edu 8.33% | 6 | 9.39% | 26689 | iljitsch@muada.com 6.94% | 5 | 7.87% | 22375 | lear@cisco.com 4.17% | 3 | 5.42% | 15404 | jordi.palet@consulintel.es 2.78% | 2 | 3.99% | 11351 | marcelo@it.uc3m.es 2.78% | 2 | 2.06% | 5848 | mbagnulo@ing.uc3m.es 1.39% | 1 | 1.43% | 4075 | huitema@windows.microsoft.com 1.39% | 1 | 1.26% | 3577 | tjc@ecs.soton.ac.uk 1.39% | 1 | 1.06% | 3025 | erik.nordmark@sun.com 1.39% | 1 | 0.90% | 2571 | sra@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 72 |100.00% | 284350 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Sun Jun 27 19:34:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12951 for ; Sun, 27 Jun 2004 19:34:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bej7E-00089P-9P for multi6-data@psg.com; Sun, 27 Jun 2004 23:31:16 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bej7A-00088P-Gq for multi6@ops.ietf.org; Sun, 27 Jun 2004 23:31:12 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5RNUpJ6006314; Sun, 27 Jun 2004 16:30:51 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5RNUh209379; Mon, 28 Jun 2004 01:30:44 +0200 (MEST) Date: Sun, 27 Jun 2004 16:30:43 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: caches and mappings To: marcelo bagnulo braun Cc: Erik Nordmark , multi6@ops.ietf.org, Joe Touch , Iljitsch van Beijnum In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk [I took the liberty to change the subject since this isn't about the persistence of the IDs; it is whether the mappings from IDs->foo can be viewed as caches or whether they are hard endpoint state] > However, i wonder if this issue is not more general and it is not > limited to only ephemeral ids proposals > > (not considering the refferral and call back cases here) > > I mean, in any proposal that manages bindings between multiple locators > that can be used to reach a single endpoint, you need some state in the > endpoints about the binding. This state has to be preserved as long as > the communication exists, and some garbage collection mechanism is > needed to delete this state after it is used. > As you mention, the wedge layer does not have knowledge about the apps > still need the binding state, so how do you know when to delete it? One possibility is that the information is a cache, similar in nature to the ARP cache, where information can be discarded because it can be rediscovered based on what exists elsewhere in the node. That would make the caching strategy a performance tradeoff - how much state to retain compared to how much does it cost to recreate the state. Given that the ULP might only have a 128 bit handle, it is hard for me to see how one can recreate the state in the presence of unreachability for some locators, without some 3rd party infrastructure. > One problem is that if the endpoints are incapable of obtaining the > locators associated with a given identifier (as in HIP), it is > impossible for the endpoints to recover the lost state, so perhaps > having a mechanism for mapping id to locators is a must? I think I agree, but I would rephrase it as For existing applictions, whatever 128-bit thing they pass to sendto() and connect(), should have the property that the multi6 layer/sublayer can create or recreate whatever state it needs based on that bit string. I wonder, assuming we are successful, there will be applications that are aware of the id/locator split thus will know to deal with both quantities instead of just a 128-bit string, which is why I rephrased it as above. Erik From owner-multi6@ops.ietf.org Sun Jun 27 19:39:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13088 for ; Sun, 27 Jun 2004 19:39:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BejE5-0009dR-D7 for multi6-data@psg.com; Sun, 27 Jun 2004 23:38:21 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BejE2-0009cT-Mg for multi6@ops.ietf.org; Sun, 27 Jun 2004 23:38:18 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5RNcAJ6007832; Sun, 27 Jun 2004 16:38:11 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5RNc5210050; Mon, 28 Jun 2004 01:38:05 +0200 (MEST) Date: Sun, 27 Jun 2004 16:38:05 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: identity persistence and comparison issues To: Iljitsch van Beijnum Cc: Erik Nordmark , Multi6 In-Reply-To: "Your message with ID" <88E2EBF4-C5CB-11D8-A349-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > One could argue that the application should inform the "stack" about > > the lifetime of the communication, perhaps by defining some new "open" > > and "close" APIs, i.e. getting close to defining a session layer. > > But my gut feel is that this requires more changes to the applications > > than is warranted. > > Hm, I think you're overlooking the fact that in any case where > referrals happen, the host that's being referred to must accept > incoming connections. An application waiting for incoming connections > is something that's pretty easy to detect for a host stack... I think you're overlooking that UDP doesn't have the concept of incoming connections :-) Seriously, I don't see how we can make any detection/heuristic that can determine whether the identifier needs to be able to survive across e.g. multiple socket calls at the API. > In other words, the bind(2) call can trigger the creation of a > longer-lived identifier. Still, I'm not sure how applications determine > which address to use in referrals, it may be necessary to make this an > explicit API call = application changes = a bad thing. But even this is hard for TCP unless I misunderstand your idea. Suppose an application which doesn 1. Client connects to the server. 2. Client asks server do perform X. 3. The server might be able to perform X immediately in which case it returns the results on the same connection, or the server says "I'll call you back later". In the second case we get 4. Client creates listening socket. Tells the port number to the server. 5. Existing socket is closed 6. Later server calls back the client In this case the server takes the "identity" (getpeername()) from the connection created in 1 as the place to call back. Thus allocating a longer-lived identifier in 4 wouldn't help, unless you want to modify the application. Erik From owner-multi6@ops.ietf.org Sun Jun 27 19:53:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13544 for ; Sun, 27 Jun 2004 19:53:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BejRI-000BJn-HG for multi6-data@psg.com; Sun, 27 Jun 2004 23:52:00 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BejRF-000BJH-Rk for multi6@ops.ietf.org; Sun, 27 Jun 2004 23:51:57 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5RNpsJ6010353; Sun, 27 Jun 2004 16:51:54 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5RNpk210798; Mon, 28 Jun 2004 01:51:46 +0200 (MEST) Date: Sun, 27 Jun 2004 16:51:46 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: about Wedgelayer 3.5 / Fat IP approaches To: marcelo bagnulo braun Cc: Multi6 List In-Reply-To: "Your message with ID" <9E2C48E6-C5F6-11D8-97AE-000D93ACD0FE@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Among the multiple approaches that have been included within the > Wedgelayer 3.5 / Fat IP class, we can find very different mechanisms > imho. I I think that additional discussion is needed to understand > which one of the different approaches (not particular solution, but > general approach) would better fulfill our needs. the goal of this > message is then, to provide my opinion of some of the benefits and > limitations of each approach in order to foster discussion of this > topic. > > So, as is see it the approaches included within the Wedgelayer 3.5 / > Fat IP class use the following types of ULP identifiers: > - 128 bit long CBIDs (HIP, SIM) > - CGAs (cb64) > - Locators (i.e. the use a locators as the ULP id) (NOID, ODT) > - ephemeral ids (WIMP, MAST?) What I'm about to write might make things more confusing, but hopefully also more clear. I think conceptually we are using identifiers for two different purposes, but in many (not all) cases the same bit strings serve both purposes. 1. A handle passed to the applications that can be used for things like - comparisons - callbacks and referrals 2. A thing used inside the multi6 (sub)layer as part of preventing redirection attacks. A current case where they are not the same is in the (now expired) cb64 draft, where the application sees a 128-bit handle with IP address semantics, but the multi6 layer uses the 64 last bits as a hash of a public key. In Santa Monica after the meeting Jukka Ylitalo brought up another interesting thing to try; using NOID-style AIDs with WIMP ephemeral IDs underneath. (Sounds a bit complex to me, but well worth exploring to further our understanding in this space.) Furthermore, we definitely need to be concerned about #1 for existing applications. But it migth also make sense to think about applications that have been modified to be multi6-aware. For instance, calling the getpeername() API might return what is essentially a designated locator for the peer, which provides support for unmodified applications. But we could decide to crate getpeerid() and getpeerlocators() which would return more information to modified applications. This might mean that unmodified applications would receive limited support for callbacks and referrals when a locator becomes unreachable, but the modified applications would be robust against such failures. Erik From owner-multi6@ops.ietf.org Mon Jun 28 03:32:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14185 for ; Mon, 28 Jun 2004 03:32:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Beqa0-0008Ve-La for multi6-data@psg.com; Mon, 28 Jun 2004 07:29:28 +0000 Received: from [131.160.193.2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BeqZr-0008Ut-BC for multi6@ops.ietf.org; Mon, 28 Jun 2004 07:29:20 +0000 Received: from nomadiclab.com (n45.nomadiclab.com [131.160.193.45]) by n2.nomadiclab.com (Postfix) with ESMTP id 67F96212C31; Mon, 28 Jun 2004 10:29:18 +0300 (EEST) Message-ID: <40DFC89A.8080400@nomadiclab.com> Date: Mon, 28 Jun 2004 10:28:26 +0300 From: Jukka Ylitalo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo braun Cc: Joe Touch , Erik Nordmark , multi6@ops.ietf.org, Iljitsch van Beijnum Subject: Re: identity persistence and comparison issues References: <40DB743C.8060005@isi.edu> <34CB9FE4-C683-11D8-97AE-000D93ACD0FE@ing.uc3m.es> In-Reply-To: <34CB9FE4-C683-11D8-97AE-000D93ACD0FE@ing.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo braun wrote: > > Yes, but for how long does the hip endpoint maintains the mapping > between the HIT and the locators of the other endpoints? HIP: For my best understanding, the HIP I-D does not explicitly specify the context lifetime. Although, the IPSec Security Association lifetime plays an important role in HIP. In our HIP implementation the IPSec SA is stricly bound to the HIP context. Once the SA is deleted, so will be the corresponding HIP context. When the SA lifetime expires, the IPSec typically triggers an UPDATE message updating the SA. In our implementation, if the UPDATE exchange fails, the host destroys the corresponding HIP context. In addition, in BSD, if there are no traffic within t seconds, the SA expiration does not trigger a new UPDATE message, but just deletes the SA, and as a consequence also the HIP context. Multi6: It seems to me that Multi6 wedge3.5 protocols could benefit from IPSec SA kind of semantics. That is, each host specifies its own policy for context lifetime. (It is good to notice that this proposal is not related to actual IPSec in anyway). Once the context lifetime expires, it triggers a new context lifetime update exhange. If the Multi6 implementation does not find out any traffic during a while, it just deletes the context (like with IPSec in BSD). However, the next packet sent via the open socket would trigger a new full context establishment exchange. Any opinions? > > I mean, there must be a garbage collection mechanism, if not the hip > endpoint will have to store infromation about all the endpoints that > it has communicated with in the past > You are right that there exists a problem. A host that destroys a HIP context may still have an open socket bound to HITs. Now, if an application sends a packet using the HITs, the packet triggers new HIP base exchange. However, the host does not have anymore information about the destination locators where to send the HIP base exchange packets. Thus, we end up with problems. I would like to see a Multi6 variant of HIP that uses routable IP-addresses as application identifers, instead of HITs. (I will return to this topic in my reply to Erik, in the next mail.) br, Jukka -- Jukka Ylitalo Tel: +358 9 299 2622 NomadicLab, Ericsson Research Fax: +358 9 299 3535 Oy L M Ericsson Ab Mobile: +358 400 615 821 FIN-02420 Jorvas, Finland E-mail: jukka.ylitalo@nomadiclab.com From owner-multi6@ops.ietf.org Mon Jun 28 04:11:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15653 for ; Mon, 28 Jun 2004 04:11:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BerDT-000Cyl-Mb for multi6-data@psg.com; Mon, 28 Jun 2004 08:10:15 +0000 Received: from [131.160.193.2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BerDK-000CyE-TK for multi6@ops.ietf.org; Mon, 28 Jun 2004 08:10:07 +0000 Received: from nomadiclab.com (n45.nomadiclab.com [131.160.193.45]) by n2.nomadiclab.com (Postfix) with ESMTP id EEBD3212C0B; Mon, 28 Jun 2004 11:10:05 +0300 (EEST) Message-ID: <40DFD22A.8080705@nomadiclab.com> Date: Mon, 28 Jun 2004 11:09:14 +0300 From: Jukka Ylitalo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: marcelo bagnulo braun , Multi6 List Subject: Re: about Wedgelayer 3.5 / Fat IP approaches References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >What I'm about to write might make things more confusing, but hopefully >also more clear. > >I think conceptually we are using identifiers for two different purposes, >but in many (not all) cases the same bit strings serve both purposes. >1. A handle passed to the applications that can be used for things like > - comparisons > - callbacks and referrals >2. A thing used inside the multi6 (sub)layer as part of preventing redirection > attacks. > > > I agree. I would like to speak about the 'context ownership problem' in the second case. For example, - HIP has two different kind of application identifiers: Local Scope Identifiers for IPv4 sockets, and HITs for IPv6. In both case, the HIP layer uses public key crypto to prove the ownership of the same context. - WIMP uses ephemeral identifiers and hashes of FQDN at application layer. However, it uses hash chains to prove the context ownership. >A current case where they are not the same is in the (now expired) cb64 draft, >where the application sees a 128-bit handle with IP address semantics, >but the multi6 layer uses the 64 last bits as a hash of a public key. >In Santa Monica after the meeting Jukka Ylitalo brought up another interesting >thing to try; using NOID-style AIDs with WIMP ephemeral IDs underneath. >(Sounds a bit complex to me, but well worth exploring to further our >understanding in this space.) > > > Thanks for bringing this out. Yes, the initiator would use, WIMP kind of, ephemeral identifiers (random numbers), and the responder, NOID kind of, routable IP-addresses at the application layer. >Furthermore, we definitely need to be concerned about #1 for existing >applications. But it migth also make sense to think about applications >that have been modified to be multi6-aware. > > I feel that we should use routable identifiers with the connect() and sento() kind of function calls in any case. This makes it possible to be backward compatible with existing applications. However, the client side may use non-routable application identifiers. (Thus, the context establishment is asymmetric process, and two host may finally have two diferent context-pairs with them.) It would be also possible to change HIP in a way that the applications were to see routable IP-addresses, instead of HITs. Basically, the Multi6 enhanced HIP would implement a NOID kind of AID-locator split. In this way, it would be possible to use HIP in an opportunistic mode, like SSH. I believ that the application layer will be the key element when combining different wedge3.5 proposals. Finally, the application identifier type is related to security properties of any Multi6 protocol. As Marcelo wrote, we should analyze those properties of different AIDs better and apply them with context ownership properties. >For instance, calling the getpeername() API might return what is essentially >a designated locator for the peer, which provides support for unmodified >applications. But we could decide to crate getpeerid() and getpeerlocators() >which would return more information to modified applications. >This might mean that unmodified applications would receive limited >support for callbacks and referrals when a locator becomes unreachable, >but the modified applications would be robust against such failures. > > Erik > > > > > > -- Jukka From owner-multi6@ops.ietf.org Mon Jun 28 04:36:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16387 for ; Mon, 28 Jun 2004 04:36:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BeraT-000Ejg-Fs for multi6-data@psg.com; Mon, 28 Jun 2004 08:34:01 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BeraF-000Eib-6y for multi6@ops.ietf.org; Mon, 28 Jun 2004 08:33:47 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5S8ZD2r065831; Mon, 28 Jun 2004 10:35:14 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: identity persistence and comparison issues Date: Mon, 28 Jun 2004 10:33:45 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 28-jun-04, at 1:38, Erik Nordmark wrote: >> Hm, I think you're overlooking the fact that in any case where >> referrals happen, the host that's being referred to must accept >> incoming connections. An application waiting for incoming connections >> is something that's pretty easy to detect for a host stack... > I think you're overlooking that UDP doesn't have the concept of > incoming > connections :-) Sure it has, the connections just don't last longer than one packet. (-: I haven't written anything that handles incoming UDP packets, so I don't know for sure, but unless I'm very much mistaken applications need to do a bind() call before they can receive UDP packets too. > Seriously, I don't see how we can make any detection/heuristic that > can determine whether the identifier needs to be able to survive > across e.g. multiple socket calls at the API. Yes, this can be a problem that may require application changes to solve. > Suppose an application which doesn > 1. Client connects to the server. > 2. Client asks server do perform X. > 3. The server might be able to perform X immediately in which case it > returns > the results on the same connection, > or the server says "I'll call you back later". > In the second case we get > 4. Client creates listening socket. Tells the port number to the > server. > 5. Existing socket is closed > 6. Later server calls back the client > In this case the server takes the "identity" (getpeername()) from > the connection created in 1 as the place to call back. > Thus allocating a longer-lived identifier in 4 wouldn't help, > unless you want to modify the application. I don't think I see your problem. If the system uses a long-lived identifier at step 4, and the application obtains this identifier from the system, we're in business, I think. The problems start when the app tries to discover the identifier before step 4 and it obtains a short-lived one. From owner-multi6@ops.ietf.org Mon Jun 28 05:13:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18297 for ; Mon, 28 Jun 2004 05:13:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BesBF-000Igh-9a for multi6-data@psg.com; Mon, 28 Jun 2004 09:12:01 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BesB6-000Ifs-Fg for multi6@ops.ietf.org; Mon, 28 Jun 2004 09:11:52 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i5S9Bd0R029047; Mon, 28 Jun 2004 02:11:40 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5S9BT210650; Mon, 28 Jun 2004 11:11:29 +0200 (MEST) Date: Mon, 28 Jun 2004 00:45:17 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft remarks To: Iljitsch van Beijnum Cc: Multi6 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Sorry for the delay in responding and thank you for the comments. > draft-nordmark-multi6-threats-02 > > 1.1 I think the assumption that an attacker can do everything is > dangerous, as this isn't a typical capability that an attacker would > have. It's much more common that an attacker can just monitor, or > monitor and inject but not block. Countermeasures that address these > threats but not the one where an attacker can also block traffic could > still be useful. I don't have a problem adding a caveat about this in 1.1, but I'm trying to understand the cases that you are thinking off. On-path attackers that need to monitor might be lucky and find a non-switched Ethernet in the path, or use capacitive or inductive coupling to listen on a copper wire. But if the attacker is on an Ethernet that is on the path, whether switched or not, the attacker can also employ ARP/ND spoofing to get access to the packet flow which allows blocking as well. Similarely, if the attacker has access to the wire, the attacker can also place a device on the wire to block. Other on-path attacks would be those that gain control of a router or a switch (or gain control of one of the endpoints) and I think those would allow blocking as well. So the strongest case I can think of for monitoring (and injecting?) being easier than blocking is when switches and routers have monitoring capabilities (for network management or for lawful intercept) where an attacker might be able to bypass the authentication and authorization checks for those capabilities. Are there others that you have in mind? > 2- ULP I think that the definition of ULP clashes with other uses of > the term, where it is used as "anything above the network layer" or > "anything above the layer under discussion". The current definition is > largely the same as "transport layer" if we ignore some more esoteric > protocols that run on top of IP (such as ICMP) which are special cases > with regard to multihoming anyway. I see the definition has "immediately above IP" which actually wasn't the intent. The intent was anything "above the network layer". If I say "any layer above IP" and add some words about applications would that correct things? > 2 - address "unique identifier" can be read as "only identifier" but > means "that uniquely identifies". Will fix. > 2 - identifier If not associated with an interface, then with what? > (Host, of course... But what is a "host"?) I'll add explicit mention of host. Something like: identifier - an IP layer identifier for an IP layer endpoint ( (stack name in [NSRG]), that is, something that might be commonly referred to as a "host". Is the "what is a host" a question you think the draft needs to address? > 3.4 Slow down packets? Example please... I'll add: that is, X can disable any flow or congestion control mechanism such as Explicit Congestion Notification [ECN]. > Page 17: "signally"? fixed > BTW, it occurs to me that we can avoid some problems by imposing some > restrictions on the FQDN <-> (identifier) <-> IP address/locator > relationship(s). I.e., no longer allowing an FQDN to point to more than > one host. Would this be a reasonable thing to do and/or useful? I think that's out of the scope for the threats draft. If we are talking about a solution, I don't think it is necessary to add such a restriction. The revision to NOID I hope to finish soon allows FQDNs that point at multiple hosts as a result of being robust against inconsistencies in the DNS information and the configuration of the host itself. Thus the peers would exchange their locators in the clear and the non-null intersection between what the peer said and what the DNS said about the peer will be used. > Re 3.4: I think it would be possible to mitigate many of the problems > here by including a periodic state refresh and disallowing adding new > locators when the original address which has been "validated" using > return routability is no longer reachable. I think preventing 3rd party flooding attacks doesn't have to be very complicated. But are you proposing that a node could send to a locator without having any assurance that the peer is in fact present at that locator i.e. without any form of RR check? > 4.3 can be addressed by reflecting the original address back so if the > negotiation is corrupted by an attacker at least there is a way to > trace this back part of the way. Are you commenting on the first paragraph of 4.3? The more specific details in 4.3.1 and 4.3.2 seems to indicate to me that you actually need to verify that the peer is present at the claimed locator. > About 5: a good start would be to make a split between the state for > incoming and outgoing sessions. But isn't that hard for UDP, when the kernel stack doesn't explicitly know who started the communication? > Having to do work per session may not > be so bad if there is a way to quickly sync up with the state that's > already there for older sessions. Both hosts would then know they're > still talking to the same correspondent. If this fails (maybe > legitimate loss of state due to timeout) they can fall back to a full > session initialization. But wouldn't such an ability to securely resume a previous session require that some state is retained from that session i.e. the session state isn't really removed? How would this be different than just keeping all the session state? In either case there would be some timeout or other garbage collection trigger to remove the state I think. > Maybe a stupid idea, but would it be useful to have some mechanism to > discover insecure links? A simple way to do this would be blocking > (initial) multi6 packets on such links so initiating multihoming > negotiations over such unsafe links which may lead to later redirection > attacks becomes impossible. Apart from the policy question, where different hosts might consider different things "secure" vs. "not secure", would it be possible to make any form of automatic detection of anything but the link attached to the host? Do you have a concrete example of how such a thing could work and be used? Erik From owner-multi6@ops.ietf.org Mon Jun 28 05:14:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18431 for ; Mon, 28 Jun 2004 05:14:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BesCX-000In5-RI for multi6-data@psg.com; Mon, 28 Jun 2004 09:13:21 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BesCP-000Ili-ES for multi6@ops.ietf.org; Mon, 28 Jun 2004 09:13:13 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i5S9B853029662; Mon, 28 Jun 2004 03:11:09 -0600 (MDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5S9Cr210804; Mon, 28 Jun 2004 11:12:54 +0200 (MEST) Date: Mon, 28 Jun 2004 02:12:52 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-nordmark-multi6-threats-01.txt To: marcelo bagnulo braun Cc: Erik Nordmark , Multi6 List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk [Sorry for the delay in responding. I think this is still relevant to our discussion, at least we need to understand how to make the "granularity" section say what we want it to say.] > > If they do believe that they are having confidential > > communication with Santa Claus but they are instead communicating > > (with confidentiality) with me then there was an attack on > > confidentiality. > > But even if it is a non confidential communication, if i think that i > am communicating with santa, but i am communicating with someone else, > this is a problem We're not discussing the importance of preventing redirect attacks here. The issue is/was how we describe it at the highest level. > Ok, it is clear to me now. The RST example was helpful for me, perhaps > adding it may help others. I'll add it. > For instance, you can think a solution where each connection is handled > independently, and has its own security, So attackers have to redirect > each connection independently, no matter the direction the connection > is established. Examples of this are solutions that make TCP to support > multiple addresses per connection. Yes, but it is hard to see how such an approach would apply to UDP. And I think applying such a TCP solution to http traffic would be insane due to the performance impact of doing more work for every short connection. Even so, since there are long-lived http connections, I think it would be bad to remove the ability for them to benefit from multihoming. So you'd definitely need a MAST type approach here were the signalling can be deferred until you can guess that the connection will be long lived enough to benefit from the multihoming state being established. > Next, you have solutions that explicitly handle different directions of > communication separately. This means that all incoming communications > from a given endpoint share the same set of locators, and an attack > will affect established and future incoming communication evenly. the > same for outgoing communications. I guess that an example of this would > be wimp. This makes sense, imho because as you mention in the draft, > the initiator role and the responder role are different in terms of > identity requirement. In many cases the identity of the initiator is > not very important, the only relevant issue is that it remains the same > that had initiated the communication. OTOH, the receiver identity is > always important since the initiator wants to communicate with a > certain host. Hmm - perhaps "incoming" and "outgoing" is being overloaded when we take WIMP into account. I view WIMPs use of ephemeral IDs as a separate step of creating an identity on the fly which is conceptually separate from that node initiating communication by sending a UDP packet or a TCP SYN. But perhaps I'm confused... > Finally, some solutions handle all the communications together, > incoming and outgoing. Such solutions (like noid, sim) require heavier > security features in all communications, since no matter whether the > communication requires identity validation or not, this feature is > provided > > That is why i see that the issue to be about the scope of the binding > information. > We need some security mechanisms to negotiate the binding between a set > of locators and the identifier used by ULP > The point is the scope of this binding. > This binding can affect only a a given communication > this binding can affect all the incoming (or outgoing) communications > this binding can affect all the communications with a given endpoint. > > As the binding affects more communications, the security required for > the mechanism to set up the binding would be stronger, imho You seem to be basing this on the assumption that each communication provides a fixed security quantum and it is the sum of these quanta over all all communication that matters. That doesn't make sense to me, since I don't think things are that uniform. For example, the communication which a sensor initiates to report a fire has higher security requirements (for instance, needs higher DoS resistance) than periodic temperature readings from the same sensor (that might be used to fine tune the air conditioning settings). I care a lot more about the security when accessing my bank than when accessing a news site. Thus not all communication have the same security requirements. Hence assuming a fixed security "contribution" per communication doesn't make sense to me. > i think this is a good point. > When considering per connection solutions, the time is naturally > limited to the lifetime of the connection. The problem is when you > attempt to use the binding information for more than a single > connection (or when the mechanism resides in a layer that has no > knowledge of the connections) In this case, you need a garbage > collection mechanisms, to delete the bindings that are no longer being > used. As you mention, the presence of this information when it is no > longer needed for the communication is a liability, and would make > sense to delete asap I don't think I said it was a liability; when applications perform repetitive connections over a short time period there is a great benefit in being able to retain the multihoming state across those connections. Likewise if multiple parallel connections seem to be useful to some applications. My take is why per-connection TCP solutions are simpler than a common, connection indepdent solution, is two-fold: - the identifier space is effectively different. TCP cares about the 5-tuple indentifying the connection and as a result, connection redirection, but it doesn't need to care whether multiple peers are claiming to use the same 128-bit identifier as long as the connections are uniquely identified by the 5-tuple. - state setup and taredown can be bound to the open and close handshakes of the protocol. The first point is interesting to compare to ephemeral IDs. For many TCP applications the initiator's port number floats that is the 5-tuple connection identifier will be ephemeral as a result; even if the variation is less than 16 bits. This means that one can perhaps be less concerned about premeditated redirection? > > Yes, for the responding end. > > The interesting thing I tried to bring out is that for the > > end that has the ephemeral ID, you can skirt around the premediated > > attacks (assuming the solution has a robust way to pick a new ID when > > one is in use/stolen). > > Yes and the cool thing is that the node that has an ephemeral id does > no need a stable one when he is acting as an initiator, so providing it > to him would require additional security without any benefits (which > doesn't seems a reasonable tradeoff :-) Yes, if you somehow know that the application will not try to use that ID on a longer timescale whether for identity comparison, callbacks or referrals. > But imho in the case of ephemeral ids, you are not really proving id > ownership, because the identity is meaningless! It is meaningless on a longer timescale and for the applications, but it might be critical to be able to redirect existing communication to use a different locator. Thus you can view this as a first-come first-serve ID claim protocol with any given peer; once a node has claimed an ID at the peer it can use that ID to affect the locators that are used to reach it. > So you don't really have to prove id ownership because it is irrelevant > The important point in this scenario is that the the communication is > always with the same endpoint. Exactly, which I why I say there is an ID in this case. > Ok, i agree that i should be more precise about this point. > Perhaps the important issue in this case is that a given endpoint is > authorized to use a given locator (i think G. Montenegro used this > expression about locators a while ago) > > So we need to provide identity ownership proofs and locator usage > authorization proofs in order to make this work > > So, assuming the above taxonomy of means to provide identity ownership > proof, the mechanisms to provide locator usage authorization proof > would be: > > - return routability: i.e. if an endpoint is capable of receiving > packets at a given locator, it is because he is authorized to do so > - third trusted party: a third party establishes that a given identity > is authorized to use a given set of locators (for instance the DNS) Yes. I'll try to add this into the appendix. Erik From owner-multi6@ops.ietf.org Mon Jun 28 06:03:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21159 for ; Mon, 28 Jun 2004 06:03:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Beswh-000NY2-Px for multi6-data@psg.com; Mon, 28 Jun 2004 10:01:03 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BeswV-000NWg-Gs for multi6@ops.ietf.org; Mon, 28 Jun 2004 10:00:52 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4AFDD39DF2; Mon, 28 Jun 2004 12:00:50 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 364C339706; Mon, 28 Jun 2004 12:00:50 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <2AE2F871-C8EA-11D8-97AE-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Multi6 List From: marcelo bagnulo braun Subject: Re: about Wedgelayer 3.5 / Fat IP approaches Date: Mon, 28 Jun 2004 12:01:47 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 28/06/2004, a las 1:51, Erik Nordmark escribi=F3: >> Among the multiple approaches that have been included within the >> Wedgelayer 3.5 / Fat IP class, we can find very different mechanisms >> imho. I I think that additional discussion is needed to understand >> which one of the different approaches (not particular solution, but >> general approach) would better fulfill our needs. the goal of this >> message is then, to provide my opinion of some of the benefits and >> limitations of each approach in order to foster discussion of this >> topic. >> >> So, as is see it the approaches included within the Wedgelayer 3.5 / >> Fat IP class use the following types of ULP identifiers: >> - 128 bit long CBIDs (HIP, SIM) >> - CGAs (cb64) >> - Locators (i.e. the use a locators as the ULP id) (NOID, ODT) >> - ephemeral ids (WIMP, MAST?) > > What I'm about to write might make things more confusing, but = hopefully > also more clear. > > I think conceptually we are using identifiers for two different=20 > purposes, > but in many (not all) cases the same bit strings serve both purposes. > 1. A handle passed to the applications that can be used for things = like > - comparisons > - callbacks and referrals > I would add initial contact to this list. I mean, an initiator must=20 have a stable string to properly indicated the other endpoint of the=20 communication. > 2. A thing used inside the multi6 (sub)layer as part of preventing=20 > redirection > attacks. > This would be essentially what pbk deals with, i guess Would it be correct to say that the applications have to be aware of=20 the string used for #1 but it is not required that apps are aware of=20 the string used for #2? (i am highlighting the *internal* of the #2) > A current case where they are not the same is in the (now expired)=20 > cb64 draft, > where the application sees a 128-bit handle with IP address semantics, > but the multi6 layer uses the 64 last bits as a hash of a public key. > In Santa Monica after the meeting Jukka Ylitalo brought up another=20 > interesting > thing to try; using NOID-style AIDs with WIMP ephemeral IDs = underneath. > (Sounds a bit complex to me, but well worth exploring to further our > understanding in this space.) this would mean that you would use hash chains values for #2 and=20 regular ip addresses for #1? > > Furthermore, we definitely need to be concerned about #1 for existing > applications. But it migth also make sense to think about applications > that have been modified to be multi6-aware. > > For instance, calling the getpeername() API might return what is=20 > essentially > a designated locator for the peer, which provides support for=20 > unmodified > applications. But we could decide to crate getpeerid() and=20 > getpeerlocators() > which would return more information to modified applications. > This might mean that unmodified applications would receive limited > support for callbacks and referrals when a locator becomes = unreachable, > but the modified applications would be robust against such failures. > Another case, imho would be to consider a non multi6 aware application=20= running on a multi6 aware host. In this case, the multi6 layer could provide enhanced services and=20 preserve connectivity even if the locator used on the refferral or call=20= back becomes unreachable. So i guess that we can have 4 cases: a- non multi6 aware app running on a non multi6 aware host: in this=20 case a locator must be used for refferals b- non multi6 aware app running on a multi6 aware host: in this case=20 the app will pass the 128 bit string that it is using to the other end.=20= So the multi6 layer has to be capable to obtain the locator set form=20 this 128 bit string i.e. we need an id to locator mapping mechanism c- multi6 aware app running on a non multi6 aware host: the app could=20 pass both the id and the locator set, We don't need nothing more than=20 upgrading all the apps :-) d- multi6 aware app running on a multi6 aware host: both solutions work=20= fine imho, an appealing approach would be one that uses valid locators as=20 ids, in order to support a) and since we are using locaotrs, we can use=20= the reverse DNs to provide the mapping system needed for b) regards, marcelo > Erik > From owner-multi6@ops.ietf.org Mon Jun 28 06:16:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22124 for ; Mon, 28 Jun 2004 06:16:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BetA7-000PYB-JP for multi6-data@psg.com; Mon, 28 Jun 2004 10:14:55 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bet9t-000PXC-G6 for multi6@ops.ietf.org; Mon, 28 Jun 2004 10:14:42 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AF10F39E1B; Mon, 28 Jun 2004 12:14:40 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 951C639E0E; Mon, 28 Jun 2004 12:14:40 +0200 (CEST) In-Reply-To: <40DFD22A.8080705@nomadiclab.com> References: <40DFD22A.8080705@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <19CD73A6-C8EC-11D8-97AE-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Multi6 List , Erik Nordmark From: marcelo bagnulo braun Subject: Re: about Wedgelayer 3.5 / Fat IP approaches Date: Mon, 28 Jun 2004 12:15:37 +0200 To: Jukka Ylitalo X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 28/06/2004, a las 10:09, Jukka Ylitalo escribi=F3: >> > Thanks for bringing this out. Yes, the initiator would use, WIMP kind=20= > of, > ephemeral identifiers (random numbers), and the responder, > NOID kind of, routable IP-addresses at the application layer. > The problem is that some apps may need to make a refferal of the=20 initiator, which AFAIU is using an ephemeral id. I mean, by using a stable id for the receiver you solve the problem of=20= the initial cntact, but imho not the refferal problem, since the=20 initiator can also be reffered. I mean, apps that are not client/server=20= wouldn't be properly supported by this model, afaics >> Furthermore, we definitely need to be concerned about #1 for existing=20= >> applications. But it migth also make sense to think about=20 >> applications >> that have been modified to be multi6-aware. >> > I feel that we should use routable identifiers with the connect() > and sento() kind of function calls in any case. This makes it possible=20= > to be > backward compatible with existing applications. However, the client > side may use non-routable application identifiers. (Thus, the context > establishment is asymmetric process, and two host may finally have two > diferent context-pairs with them.) > > It would be also possible to change HIP in a way that the applications > were to see routable IP-addresses, instead of HITs. Basically, the=20 > Multi6 > enhanced HIP would implement a NOID kind of AID-locator split. In this=20= > way, > it would be possible to use HIP in an opportunistic mode, like SSH. > I believ that the application layer will be the key element when=20 > combining different > wedge3.5 proposals. > > Finally, the application identifier type is related to security=20 > properties of > any Multi6 protocol. As Marcelo wrote, we should analyze those > properties of different AIDs better and apply them with context > ownership properties. > what about cgas? They are locators, so you can use them for refferals to non multi6 apps=20= and hosts, they allow to map from id to locators using reverse dns, and=20= they are crypto in nature seems a good candidate to me :-) regards, marcelo PS: i will reread the CB64 draft >> For instance, calling the getpeername() API might return what is=20 >> essentially >> a designated locator for the peer, which provides support for=20 >> unmodified >> applications. But we could decide to crate getpeerid() and=20 >> getpeerlocators() >> which would return more information to modified applications. >> This might mean that unmodified applications would receive limited=20 >> support for callbacks and referrals when a locator becomes=20 >> unreachable, >> but the modified applications would be robust against such failures. >> >> Erik >> >> >> >> >> > -- Jukka > > From owner-multi6@ops.ietf.org Mon Jun 28 06:17:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22231 for ; Mon, 28 Jun 2004 06:17:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BetBe-000Pim-8x for multi6-data@psg.com; Mon, 28 Jun 2004 10:16:30 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BetBT-000Phr-Pq for multi6@ops.ietf.org; Mon, 28 Jun 2004 10:16:20 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5SAHj2r068056; Mon, 28 Jun 2004 12:17:46 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <30987B70-C8EC-11D8-8793-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: identity persistence and comparison issues Date: Mon, 28 Jun 2004 12:16:16 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 28-jun-04, at 11:32, Erik Nordmark wrote: >> Sure it has, the connections just don't last longer than one packet. >> (-: > Ah - so "connection" survivability for UDP-based apps then becomes > quite easy > since the problem doesn't exist :-) Well, yes. But UDP really needs the ability to set up new connections very badly... 8-) > I don't know what the API standards say, but in many implementations > the app can just do a sendto() which will make UDP pick a port number > for the duration of the lifetime of the socket. Thus the application > will be able to receive packets sent in to that port number. Ok, I don't have enough information to determine whether this is a show stopper or not. > The problem is that the unmodified server extracts the identifier (aka > IP > address) in step2 thus you'd need to make the client pick a long-lived > identifier in step1, or make step4 pass the identifier+port to the > server. > In either case this implies modifications to the application. What if we just always show the application a long-lived identifier, even though when it sets up a session we use ephemeral identifiers? If the application then doesn't do referrals there is no issue as the long-lived identifier doesn't leave the host. If it does "contact me at xxx" type referrals there is also no problem as xxx is the long-lived identifier so the reference remains valid over (a reasonable amount of) time. Only in the case of "you'll hear from me and I'm xxx" type referrals wouldn't work, but those won't work reliably in the presence of multiple addresses anyway. Obviously there can be a new API call that allows applications to find the actual identifier used. From owner-multi6@ops.ietf.org Mon Jun 28 06:33:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23121 for ; Mon, 28 Jun 2004 06:33:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BetQI-0001QL-Go for multi6-data@psg.com; Mon, 28 Jun 2004 10:31:38 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BetQ7-0001P4-6f for multi6@ops.ietf.org; Mon, 28 Jun 2004 10:31:27 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5S9Nqil026025; Mon, 28 Jun 2004 03:24:02 -0600 (MDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5S9Nj211984; Mon, 28 Jun 2004 11:23:46 +0200 (MEST) Date: Mon, 28 Jun 2004 02:23:44 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: identity persistence and comparison issues To: Jukka Ylitalo Cc: marcelo bagnulo braun , Joe Touch , Erik Nordmark , multi6@ops.ietf.org, Iljitsch van Beijnum In-Reply-To: "Your message with ID" <40DFC89A.8080400@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > It seems to me that Multi6 wedge3.5 protocols could benefit from IPSec SA > kind of semantics. That is, each host specifies its own policy for > context lifetime. > (It is good to notice that this proposal is not related to actual IPSec > in anyway). > Once the context lifetime expires, it triggers a new context lifetime > update exhange. > If the Multi6 implementation does not find out any traffic during a > while, it > just deletes the context (like with IPSec in BSD). However, the next packet > sent via the open socket would trigger a new full context establishment > exchange. A potential problem (don't know how serious it is for multi6) with having each end indepdently decide when to discard its state is that you can end up with one end retaining state and the other not. Normally this is not an issue, but when the end which retained the state (call it A) again wants to communicat with the other (call it B) then B will need to send back some error saying "I've lost or intentionally discarded my state". With such a mechanism one might need to be careful about attackers, which were not on the path when communication started but has since arrived on the path, being able to fake the "lost state" message thereby being able to insert itself as a MiTM. The problem is we don't have any existing (IPv4) experience to compare with there to determine whether this is something we need to be concerned about, because so far nodes have not been moving around that much in the topology. I don't know if there are examples of attacks at WiFi hotspots that can help us understand whether we need to be concerned about this. If we do, one potential way to address it would be for the endpoints to coordinate discarding their state e.g by using timers known to the peer and/or explicit messages. Erik can end up with the case when either end From owner-multi6@ops.ietf.org Mon Jun 28 06:35:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23314 for ; Mon, 28 Jun 2004 06:35:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BetT0-0001kd-Ol for multi6-data@psg.com; Mon, 28 Jun 2004 10:34:26 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BetSq-0001it-9u for multi6@ops.ietf.org; Mon, 28 Jun 2004 10:34:16 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5S9Weil029560; Mon, 28 Jun 2004 03:32:40 -0600 (MDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5S9WZ212746; Mon, 28 Jun 2004 11:32:35 +0200 (MEST) Date: Mon, 28 Jun 2004 02:32:34 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: identity persistence and comparison issues To: Iljitsch van Beijnum Cc: Erik Nordmark , Multi6 In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Sure it has, the connections just don't last longer than one packet. > (-: Ah - so "connection" survivability for UDP-based apps then becomes quite easy since the problem doesn't exist :-) > I haven't written anything that handles incoming UDP packets, so I > don't know for sure, but unless I'm very much mistaken applications > need to do a bind() call before they can receive UDP packets too. I don't know what the API standards say, but in many implementations the app can just do a sendto() which will make UDP pick a port number for the duration of the lifetime of the socket. Thus the application will be able to receive packets sent in to that port number. > > 1. Client connects to the server. > > 2. Client asks server do perform X. > > 3. The server might be able to perform X immediately in which case it > > returns > > the results on the same connection, > > or the server says "I'll call you back later". > > In the second case we get > > 4. Client creates listening socket. Tells the port number to the > > server. > > 5. Existing socket is closed > > 6. Later server calls back the client > I don't think I see your problem. If the system uses a long-lived > identifier at step 4, and the application obtains this identifier from > the system, we're in business, I think. The problems start when the app > tries to discover the identifier before step 4 and it obtains a > short-lived one. The problem is that the unmodified server extracts the identifier (aka IP address) in step2 thus you'd need to make the client pick a long-lived identifier in step1, or make step4 pass the identifier+port to the server. In either case this implies modifications to the application. Erik From owner-multi6@ops.ietf.org Mon Jun 28 06:41:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23750 for ; Mon, 28 Jun 2004 06:41:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BetYy-0002TM-4T for multi6-data@psg.com; Mon, 28 Jun 2004 10:40:36 +0000 Received: from [131.160.193.2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BetYm-0002Rh-IY for multi6@ops.ietf.org; Mon, 28 Jun 2004 10:40:25 +0000 Received: from nomadiclab.com (n45.nomadiclab.com [131.160.193.45]) by n2.nomadiclab.com (Postfix) with ESMTP id CB73B212C0B; Mon, 28 Jun 2004 13:40:23 +0300 (EEST) Message-ID: <40DFF563.5020809@nomadiclab.com> Date: Mon, 28 Jun 2004 13:39:31 +0300 From: Jukka Ylitalo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo braun Cc: Multi6 List , Erik Nordmark Subject: Re: about Wedgelayer 3.5 / Fat IP approaches References: <40DFD22A.8080705@nomadiclab.com> <19CD73A6-C8EC-11D8-97AE-000D93ACD0FE@it.uc3m.es> In-Reply-To: <19CD73A6-C8EC-11D8-97AE-000D93ACD0FE@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit marcelo bagnulo braun wrote: > > El 28/06/2004, a las 10:09, Jukka Ylitalo escribió: > >>> >> Thanks for bringing this out. Yes, the initiator would use, WIMP kind >> of, >> ephemeral identifiers (random numbers), and the responder, >> NOID kind of, routable IP-addresses at the application layer. >> > > The problem is that some apps may need to make a refferal of the > initiator, which AFAIU is using an ephemeral id. > I mean, by using a stable id for the receiver you solve the problem of > the initial cntact, but imho not the refferal problem, since the > initiator can also be reffered. I mean, apps that are not > client/server wouldn't be properly supported by this model, afaics > Well, you are right. Next, I try to replace the current WIMP identifiers with NOID kind of AIDs for both end-points; in the next WIMP I-D. The ephemeral context identifiers together with hash chains would then be used only to identify the context. Basically, they would serve the same purpose as the purpose built-keys for initiators. That is, epheral context identifiers could be used to prevent attackers from stealing a context. (I'm trying to figure out how to bind a specific application identifier to a specific context.) (snip) > > what about cgas? > They are locators, so you can use them for refferals to non multi6 > apps and hosts, they allow to map from id to locators using reverse > dns, and they are crypto in nature > seems a good candidate to me :-) That is one alternative. However, there are some IPR issues that must be probably solved before applying cgas with multi6. > > regards, marcelo br, Jukka From owner-multi6@ops.ietf.org Mon Jun 28 07:54:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28496 for ; Mon, 28 Jun 2004 07:54:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Beugq-0009qM-JQ for multi6-data@psg.com; Mon, 28 Jun 2004 11:52:48 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Beugf-0009ov-O1 for multi6@ops.ietf.org; Mon, 28 Jun 2004 11:52:37 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5SBqTJ6008434; Mon, 28 Jun 2004 04:52:30 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5SBqL224859; Mon, 28 Jun 2004 13:52:22 +0200 (MEST) Date: Mon, 28 Jun 2004 04:52:19 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: identifiers and security To: Iljitsch van Beijnum Cc: Multi6 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk [Still catching up on older mail] > As I've said before, I think it would be useful to allow for > multihoming solutions that add a new identifier space, and also for > multihoming solutions that don't. (The new identifier space may or may > not be expressible as something that looks like an IPv6 address, but if > it is, it's not a routable IPv6 address.) Agreed. > The advantages of not having identifiers are that it's easier to be > backward compatible and less new stuff to worry about. This is a terminology nit, but I think all approaches to multihoming support have some identifier - whether it is a FQDN, or a list of locators. What is interesting is whether there is a new ID name space, as you said in the first paragraph, and whether those IDs are visible to the applications. > The irony of explicit identifiers is that they are so insecure, that > they must be protected using strong security, so they effectively > become more secure than any identifierless solution. The reason > explicit identifiers are insecure to start with is that without a > secure mapping mechanism of some sort, a correspondent is unable to > determine whether someone claiming to hold an identifier is the > legitimate owner of this identifier. Taking NOID as an example of with no new ID namespace, the amount of work (in the form of DNS lookups in forward and reverse maps) will also result in stronger association between FQDNs and locators than we have today. So I think it is inevitable that providing "do no harm" security for the multihoming will accidentally improve security a bit in some cases. I've certainly entertained ideas that are a lot weaker than NOID, for instance just have the peers exchange their sets of locators plus a cleartext cookie/context tag when the setup the state, and then do a RR check before sending packets to a new locator, but I've received pushback from folks that I wouldn't characterize as security geeks, that this would be too weak. But perhaps it is time to writeup something like that and subject it to wider scruteny, combined with your suggestion below. > I think it's important to recognize that "regular" IP operation without > the benefit of IPsec, TLS or similar authentication and what comes with > it (such as SSH) is very often insecure, and in most cases this isn't a > problematic situation. So mandating strong security in all situations > is probably a mistake. However, IPsec/TLS and the like are in wide use > for communication that must remain confidential. In those cases, the > key management problem is solved in some way or another. It would be > very beneficial to take advantage of this situation and leverage IPsec > or TLS mechanisms that are already in operation towards securing > multihoming. One way to do this is taking the IPsec or TLS "identifier" > and use it as the multihoming identifier. Architecturally this is a > nice approach, but in practice it will be hard to get off the ground, > especially with TLS as it's not always possible to determine the > authenticity of a single packet with TLS. Another approach would be to > exchange a session key that's protected using the IPsec or TLS that's > already there and protect the multihoming exchanges using this session > key. I've been trying to layer things so that IPsec and TLS benefit from the multihoming support by sitting above the layer that handles the multiple locators, and HIP essentially is layered in the same place. So perhaps one should explore, taking into account IKEv2 and MOBIKE work, an approach which layers the multihoming support above IPsec when IPsec is used? Thus something which is quite insecure (weaker than NOID as above) when IPsec isn't used, but when IPsec is used it is as strong as with IPsec in today's Internet. Is anybody interested in exploring these ideas further? Erik From owner-multi6@ops.ietf.org Mon Jun 28 08:52:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02638 for ; Mon, 28 Jun 2004 08:52:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bevaq-000Fxb-Nt for multi6-data@psg.com; Mon, 28 Jun 2004 12:50:40 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BevaJ-000FsU-SJ for multi6@ops.ietf.org; Mon, 28 Jun 2004 12:50:07 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5SCnsil015593; Mon, 28 Jun 2004 06:49:55 -0600 (MDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5SCnn229609; Mon, 28 Jun 2004 14:49:50 +0200 (MEST) Date: Mon, 28 Jun 2004 05:41:54 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: about Wedgelayer 3.5 / Fat IP approaches To: marcelo bagnulo braun Cc: Jukka Ylitalo , Multi6 List , Erik Nordmark In-Reply-To: "Your message with ID" <19CD73A6-C8EC-11D8-97AE-000D93ACD0FE@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > what about cgas? > They are locators, so you can use them for refferals to non multi6 apps > and hosts, they allow to map from id to locators using reverse dns, and > they are crypto in nature > seems a good candidate to me :-) A downside of CGA approaches is that they would, on a global basis, cast the /64 subnet prefix boundary in stone forever. This is different than SeND which only assumes the /64 on a single link, and one can envision SeND evolving to handle different subnet prefix lengths over time. Different people probably have very different level of concern for "/64 forever in stone" ranging from it being a good simplification to a fatal repeat of the 8 bit IPv4 network number + 24 bit host number (before Class B and C was invented). Erik From owner-multi6@ops.ietf.org Mon Jun 28 08:52:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02658 for ; Mon, 28 Jun 2004 08:52:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BevaH-000Frw-8d for multi6-data@psg.com; Mon, 28 Jun 2004 12:50:05 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Beva2-000FpN-9o for multi6@ops.ietf.org; Mon, 28 Jun 2004 12:49:50 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5SCnkJ6001249; Mon, 28 Jun 2004 05:49:47 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5SCnb229605; Mon, 28 Jun 2004 14:49:38 +0200 (MEST) Date: Mon, 28 Jun 2004 05:35:53 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: about Wedgelayer 3.5 / Fat IP approaches To: marcelo bagnulo braun Cc: Erik Nordmark , Multi6 List In-Reply-To: "Your message with ID" <2AE2F871-C8EA-11D8-97AE-000D93ACD0FE@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > I would add initial contact to this list. I mean, an initiator must > have a stable string to properly indicated the other endpoint of the > communication. Agreed. > > 2. A thing used inside the multi6 (sub)layer as part of preventing > > redirection > > attacks. > > > > This would be essentially what pbk deals with, i guess Yes, whether DH type pbks or hash chains - just different flavors of constructing a purpose-built secure channel. > Would it be correct to say that the applications have to be aware of > the string used for #1 but it is not required that apps are aware of > the string used for #2? Yes. There are even some APIs, such as the Java ones, that allow the applications to be unaware of even #1 by having the applications only operate using FQDNs, but I suspect that many/most applications which do callbacks and referrals need to be aware of #1. > > In Santa Monica after the meeting Jukka Ylitalo brought up another > > interesting > > thing to try; using NOID-style AIDs with WIMP ephemeral IDs underneath. > > (Sounds a bit complex to me, but well worth exploring to further our > > understanding in this space.) > > this would mean that you would use hash chains values for #2 and > regular ip addresses for #1? Yes. > > Furthermore, we definitely need to be concerned about #1 for existing > > applications. But it migth also make sense to think about applications > > that have been modified to be multi6-aware. > > > > For instance, calling the getpeername() API might return what is > > essentially > > a designated locator for the peer, which provides support for > > unmodified > > applications. But we could decide to crate getpeerid() and > > getpeerlocators() > > which would return more information to modified applications. > > This might mean that unmodified applications would receive limited > > support for callbacks and referrals when a locator becomes unreachable, > > but the modified applications would be robust against such failures. > > > > Another case, imho would be to consider a non multi6 aware application > running on a multi6 aware host. That was what I meant by "existing applications" above; existing application s on non-multi6 aware hosts would just speak IPv6 as currently defined. > In this case, the multi6 layer could provide enhanced services and > preserve connectivity even if the locator used on the refferral or call > back becomes unreachable. > So i guess that we can have 4 cases: > a- non multi6 aware app running on a non multi6 aware host: in this > case a locator must be used for refferals > b- non multi6 aware app running on a multi6 aware host: in this case > the app will pass the 128 bit string that it is using to the other end. > So the multi6 layer has to be capable to obtain the locator set form > this 128 bit string i.e. we need an id to locator mapping mechanism It is actually more constrained than that since other instances of the application might be running on non-multi6 aware hosts. So the conservative approach would be to always hand an IP address/locator to unmodified applications, that way the application can use it for callbacks and referrals without any constraints on which hosts the different instances of the app is running. > c- multi6 aware app running on a non multi6 aware host: the app could > pass both the id and the locator set, We don't need nothing more than > upgrading all the apps :-) But this would require that the application contain the logic to discover the ID and locators for its peers, whereas when running on a multi6-aware host the application could leave that task to the host (libraries etc). So it adds complexity to do this in the application, and there doesn't seem to be much benefit because the non-multi6-aware host would not be capable to make TCP connections survive a locator change etc. > d- multi6 aware app running on a multi6 aware host: both solutions work > fine > > imho, an appealing approach would be one that uses valid locators as > ids, in order to support a) and since we are using locaotrs, we can use > the reverse DNs to provide the mapping system needed for b) Yes, if the solution is going to rely on the reverse DNS for other purposes this makes sense. But if the solution doesn't, then we shouldn't require that the reverse DNS be maintained IMHO. It would be fine to take advantage of it for more robust referrals and callbacks, but not assume it will be there. Erik From owner-multi6@ops.ietf.org Mon Jun 28 08:52:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02680 for ; Mon, 28 Jun 2004 08:52:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BevaZ-000Fuz-AY for multi6-data@psg.com; Mon, 28 Jun 2004 12:50:23 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BevaJ-000FsT-Oc for multi6@ops.ietf.org; Mon, 28 Jun 2004 12:50:07 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i5SCm853023018; Mon, 28 Jun 2004 06:48:09 -0600 (MDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5SCnx229624; Mon, 28 Jun 2004 14:50:00 +0200 (MEST) Date: Mon, 28 Jun 2004 05:45:16 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: identity persistence and comparison issues To: Iljitsch van Beijnum Cc: Erik Nordmark , Multi6 In-Reply-To: "Your message with ID" <30987B70-C8EC-11D8-8793-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > What if we just always show the application a long-lived identifier, > even though when it sets up a session we use ephemeral identifiers? That's part of what Jukka and I were pondering a bit. I think it is very interesting; just need to make sure that the additional local mapping on the host from the long-lived to the ephemeral doesn't introduce attacks that we don't know how to handle. > If > the application then doesn't do referrals there is no issue as the > long-lived identifier doesn't leave the host. If it does "contact me at > xxx" type referrals there is also no problem as xxx is the long-lived > identifier so the reference remains valid over (a reasonable amount of) > time. Only in the case of "you'll hear from me and I'm xxx" type > referrals wouldn't work, but those won't work reliably in the presence > of multiple addresses anyway. And if the long-lived ID is one of the locators we can provide compatbility for unmodified applications which do referrals and callbacks. Erik From owner-multi6@ops.ietf.org Mon Jun 28 09:42:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04953 for ; Mon, 28 Jun 2004 09:42:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BewMm-000Lr7-RM for multi6-data@psg.com; Mon, 28 Jun 2004 13:40:12 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BewMU-000LoO-QK for multi6@ops.ietf.org; Mon, 28 Jun 2004 13:39:55 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F0B50396EB; Mon, 28 Jun 2004 15:39:53 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id DB4E739098; Mon, 28 Jun 2004 15:39:53 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Multi6 , Iljitsch van Beijnum From: marcelo bagnulo braun Subject: Re: identity persistence and comparison issues Date: Mon, 28 Jun 2004 15:40:51 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 28/06/2004, a las 14:45, Erik Nordmark escribi=F3: >> What if we just always show the application a long-lived identifier, >> even though when it sets up a session we use ephemeral identifiers? > > That's part of what Jukka and I were pondering a bit. > I think it is very interesting; just need to make sure that > the additional local mapping on the host from the long-lived to > the ephemeral doesn't introduce attacks that we don't know how to > handle. > Terminology questions: the application would only use the stable (long=20= lived) id, right? The ephemeral id is internal to the multi6 layer, and it is not handled=20= by the ULP, right? would then this ephemeral id would be an id, or is this simply a key or=20= a token, just as in IPSec or pbk? regards, marcelo >> If >> the application then doesn't do referrals there is no issue as the >> long-lived identifier doesn't leave the host. If it does "contact me=20= >> at >> xxx" type referrals there is also no problem as xxx is the long-lived >> identifier so the reference remains valid over (a reasonable amount=20= >> of) >> time. Only in the case of "you'll hear from me and I'm xxx" type >> referrals wouldn't work, but those won't work reliably in the = presence >> of multiple addresses anyway. > > And if the long-lived ID is one of the locators we can provide=20 > compatbility > for unmodified applications which do referrals and callbacks. > > Erik > > From owner-multi6@ops.ietf.org Mon Jun 28 10:04:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05803 for ; Mon, 28 Jun 2004 10:04:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bewi9-000ODN-FL for multi6-data@psg.com; Mon, 28 Jun 2004 14:02:17 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bewhq-000OAo-Ke for multi6@ops.ietf.org; Mon, 28 Jun 2004 14:01:59 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7C39739705; Mon, 28 Jun 2004 16:01:57 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 57E6C39098; Mon, 28 Jun 2004 16:01:57 +0200 (CEST) In-Reply-To: <40DFF563.5020809@nomadiclab.com> References: <40DFD22A.8080705@nomadiclab.com> <19CD73A6-C8EC-11D8-97AE-000D93ACD0FE@it.uc3m.es> <40DFF563.5020809@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List , Erik Nordmark From: marcelo bagnulo braun Subject: Re: about Wedgelayer 3.5 / Fat IP approaches Date: Mon, 28 Jun 2004 16:02:54 +0200 To: Jukka Ylitalo X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Next, I try to replace the current WIMP identifiers with NOID kind of > AIDs > for both end-points; in the next WIMP I-D. The ephemeral context > identifiers together > with hash chains would then be used only to identify the context. > Basically, they would > serve the same purpose as the purpose built-keys for initiators. > That is, epheral context identifiers could be used to prevent > attackers from stealing > a context. (I'm trying to figure out how to bind a specific > application identifier to > a specific context.) > I guess that we should see the details before commenting but in abstract terms, my concern would be: In its current form WIMP uses: - A hash of the FQDN as id of the receiver, and it uses the DNS to provide the required security. I mean, the mapping between the id and the FQDN is direct (id=hash(FQDN)). Next, the map between the FQDN and the locator set is provided by the DNS system (so you trust a third party to obtain such information) and so you know that if you send packets to those locators you are reaching the desired id. - for the initiator, you use an ephemeral id. In this case, you don't need to worry about all the threats, since the ephemeral id won't be valid for following communications. Basically, the only thing you need to worry about is that the endpoint that is communicating remains the same. You don't worry about id hijacking since the id is ephemeral (so it will become meaningless in a short while) Now, you are proposing to use long lived ids for the initiator as well. In this case, you solve the refferal problem, but the price is that you now have to consider all the threats that you were not considering when using ephemeral ids. So you need a mechanism to prove the initiator'r id ownership. In other words, imho hash chains are not enough in this case, and you need something else. NOID uses the DNS, HIP uses the crypto nature of its ids, what would be the mechanisms here for this? > (snip) > >> >> what about cgas? >> They are locators, so you can use them for refferals to non multi6 >> apps and hosts, they allow to map from id to locators using reverse >> dns, and they are crypto in nature >> seems a good candidate to me :-) > > That is one alternative. However, there are some IPR issues that must > be > probably solved before applying cgas with multi6. > Yes, but those issues are being worked out in other wg, as in SeND, and imho we could be optimistics about this... (but my opinion on this matter is even more meaningless than in other topics, so...) regards, marcelo >> >> regards, marcelo > > br, Jukka > > From owner-multi6@ops.ietf.org Mon Jun 28 10:58:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09636 for ; Mon, 28 Jun 2004 10:58:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BexYs-0004SM-Jw for multi6-data@psg.com; Mon, 28 Jun 2004 14:56:46 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BexYc-0004QF-8U for multi6@ops.ietf.org; Mon, 28 Jun 2004 14:56:30 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5SEuPil019418; Mon, 28 Jun 2004 08:56:25 -0600 (MDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5SEuJ212321; Mon, 28 Jun 2004 16:56:20 +0200 (MEST) Date: Mon, 28 Jun 2004 07:25:05 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: identity persistence and comparison issues To: marcelo bagnulo braun Cc: Erik Nordmark , Multi6 , Iljitsch van Beijnum In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Terminology questions: the application would only use the stable (long > lived) id, right? Yes and no. I see two reasons to be able to isolate the application from the ID used by the multihoming mechanism: 1. Allow ephemeral IDs by the multihoming mechanism. 2. Allow, perhaps stable, IDs in the multihoming mechanism that can't be used for referrals, or that are not 128-bits long (such as the FQDN as part of NOID) For both these reasons you don't want unmodified (non-multi6-aware) applications to see the internal ID. But in the case of #2 (and I haven't thought about #1) it might make sense to allow modified (multi6-aware) applications from finding the internal IDs as well as the current set of locators which are used with that ID. > The ephemeral id is internal to the multi6 layer, and it is not handled > by the ULP, right? > would then this ephemeral id would be an id, or is this simply a key or > a token, just as in IPSec or pbk? In some cases it might be just a context id/context tag (I try to avoid to use the term "session" since it implies L5 to me), but in other cases like NOID and HIP it might imply something longer like a FQDN or a public key. Erik From owner-multi6@ops.ietf.org Mon Jun 28 10:59:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09697 for ; Mon, 28 Jun 2004 10:59:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BexZI-0004V6-Bn for multi6-data@psg.com; Mon, 28 Jun 2004 14:57:12 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BexZ0-0004TH-QE for multi6@ops.ietf.org; Mon, 28 Jun 2004 14:56:54 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i5SEuf0R019954; Mon, 28 Jun 2004 07:56:42 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5SEuW212327; Mon, 28 Jun 2004 16:56:33 +0200 (MEST) Date: Mon, 28 Jun 2004 07:33:15 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: about Wedgelayer 3.5 / Fat IP approaches To: marcelo bagnulo braun Cc: Jukka Ylitalo , Multi6 List , Erik Nordmark In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > - for the initiator, you use an ephemeral id. In this case, you don't > need to worry about all the threats, since the ephemeral id won't be > valid for following communications. Basically, the only thing you need > to worry about is that the endpoint that is communicating remains the > same. You don't worry about id hijacking since the id is ephemeral (so > it will become meaningless in a short while) I think it is the FCFS per-peer allocation of the ephemeral ID that matters. Basically you don't need to worry about premeditated redirection attacks because, should a node discover that "its" ID is being used by somebody else at a particular peer, it can just invent a new empeheral ID and try that one. Thus WIMP doesn't require that the ID be renewed at any particular frequency; an ephemeral ID might be used for years. But due to the FCFS property a new ID might be allocated any time some new communication is attempted. For all I know the node can continue to use the previous ID when communicating with other peers long after the conflict had been detected at a particular peer. > Now, you are proposing to use long lived ids for the initiator as well. > In this case, you solve the refferal problem, but the price is that you > now have to consider all the threats that you were not considering when > using ephemeral ids. So you need a mechanism to prove the initiator'r > id ownership. In other words, imho hash chains are not enough in this > case, and you need something else. NOID uses the DNS, HIP uses the > crypto nature of its ids, what would be the mechanisms here for this? Don't know yet. One could potentially do the union of all of the above (yes, complexity alarms are ringing - but I still want to understand this stuff and see how bad it would be) including exploring weaker approaches like RR. Erik From owner-multi6@ops.ietf.org Mon Jun 28 11:28:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11490 for ; Mon, 28 Jun 2004 11:28:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bey21-0008CF-1O for multi6-data@psg.com; Mon, 28 Jun 2004 15:26:53 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bexyc-0007pQ-2i for multi6@ops.ietf.org; Mon, 28 Jun 2004 15:23:22 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5SFOm2r073633; Mon, 28 Jun 2004 17:24:48 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1599E638-C917-11D8-B450-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: identifiers and security Date: Mon, 28 Jun 2004 17:23:19 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 28-jun-04, at 13:52, Erik Nordmark wrote: >> The advantages of not having identifiers are that it's easier to be >> backward compatible and less new stuff to worry about. > This is a terminology nit, but I think all approaches to multihoming > support have some identifier - whether it is a FQDN, or a list of > locators. Sure, there always is an identifier, obviously I was getting at the situation where there isn't new/separate value that fulfills this function. BTW, I don't consider a _set_ of locators _a_ identifier, as membership of the set presumably isn't fixed and having more than one way to express the same identity (not the same thing as having more than one identity) is a very bad idea. (X.400 anyone?) > What is interesting is whether there is a new ID name space, as you > said in > the first paragraph, Yes. > and whether those IDs are visible to the applications. Ah, but that's a very different issue. I think by definition the identifiers are visible to the application. There are other values that may not be visible to the application and relevant, though. (And some of you may prefer to call those identifiers, but then we need another term for the application-visible values.) There are many places in the stack where (currently) the same bit string performs different functions. If we make the identifier/locator split this immediately begs the question whether that's enough, maybe we need to dig deeper. I tried to look at this a while ago in my "9 steps" (or similar) message. > Taking NOID as an example of with no new ID namespace, the amount of > work (in the form of DNS lookups in forward and reverse maps) > will also result in stronger association between FQDNs and locators > than we have today. Even if we assume DNSSEC? > So I think it is inevitable that providing "do no harm" security for > the multihoming will accidentally improve security a bit in some cases. Beware of stuff you get for free... > I've certainly entertained ideas that are a lot weaker than NOID, > for instance just have the peers exchange their sets of locators > plus a cleartext cookie/context tag when the setup the state, > and then do a RR check before sending packets to a new locator, > but I've received pushback from folks that I wouldn't characterize as > security geeks, that this would be too weak. I don't think this is universally true. Certainly, this is too weak for TLS or IPsec sessions that can now be broken by an attacker, unlike before. But why would this be too weak for talking to Google over unprotected TCP/IP? > But perhaps it is time to writeup something like that and subject it > to wider scruteny, combined with your suggestion below. Right. > I've been trying to layer things so that IPsec and TLS benefit from > the multihoming support by sitting above the layer that handles the > multiple locators, and HIP essentially is layered in the same place. > So perhaps one should explore, taking into account IKEv2 and MOBIKE > work, > an approach which layers the multihoming support above IPsec when IPsec > is used? I suppose this wouldn't be much of a problem for IPsec. This could even be done today by piping packets through a multihoming mechanism and then take the resulting packets and feed them through IPsec. Obviously this means more IPsec negotiation and state as now there must be an SA for every locator pair used rather than one for the identifier pair. I wouldn't want to try something like this with TLS, though. I'm thinking more along the line of violating layers and modify IPsec/TLS such that the wedge or modified IP can obtain keys that are exchanged by modified IPsec/TLS. Something like putting the secret instructions for the messager in the locked briefcase he's carrying. This works well except for the first trip of course... > Thus something which is quite insecure (weaker than NOID as above) when > IPsec isn't used, but when IPsec is used it is as strong as with IPsec > in > today's Internet. > Is anybody interested in exploring these ideas further? Apart from me, you mean? (-: From owner-multi6@ops.ietf.org Mon Jun 28 11:48:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12544 for ; Mon, 28 Jun 2004 11:48:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BeyKr-000AZe-0B for multi6-data@psg.com; Mon, 28 Jun 2004 15:46:21 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BeyKQ-000AW5-MZ for multi6@ops.ietf.org; Mon, 28 Jun 2004 15:45:55 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DE33539D19; Mon, 28 Jun 2004 17:45:53 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id C7D9039CF8; Mon, 28 Jun 2004 17:45:53 +0200 (CEST) In-Reply-To: <1599E638-C917-11D8-B450-000A95CD987A@muada.com> References: <1599E638-C917-11D8-B450-000A95CD987A@muada.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5F33A294-C91A-11D8-97AE-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: 7bit Cc: Multi6 , Erik Nordmark From: marcelo bagnulo braun Subject: Re: identifiers and security Date: Mon, 28 Jun 2004 17:46:51 +0200 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I've certainly entertained ideas that are a lot weaker than NOID, >> for instance just have the peers exchange their sets of locators >> plus a cleartext cookie/context tag when the setup the state, >> and then do a RR check before sending packets to a new locator, >> but I've received pushback from folks that I wouldn't characterize as >> security geeks, that this would be too weak. > > I don't think this is universally true. Certainly, this is too weak > for TLS or IPsec sessions that can now be broken by an attacker, > unlike before. But why would this be too weak for talking to Google > over unprotected TCP/IP? > >> But perhaps it is time to writeup something like that and subject it >> to wider scruteny, combined with your suggestion below. > From a security POV, how different do you think that this solution would be from a solution based in mipv6 with infinite BCE lifetimes? i mean, a RR solution would likely be very similar to the HoTI/HoT and CoTI/CoT exchange of mipv6, right? regards, marcelo From owner-multi6@ops.ietf.org Mon Jun 28 11:53:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12714 for ; Mon, 28 Jun 2004 11:53:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BeyQT-000BRT-61 for multi6-data@psg.com; Mon, 28 Jun 2004 15:52:09 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BeyQD-000BOQ-MK for multi6@ops.ietf.org; Mon, 28 Jun 2004 15:51:53 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5SFrK2r074172; Mon, 28 Jun 2004 17:53:20 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: identity persistence and comparison issues Date: Mon, 28 Jun 2004 17:51:50 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 28-jun-04, at 14:45, Erik Nordmark wrote: > And if the long-lived ID is one of the locators we can provide > compatbility > for unmodified applications which do referrals and callbacks. We should really talk to some apps people to figure out how important this is. It's entirely trivial to shoot yourself in the foot today with NAT or multiple addresses anyway, and then there is dual stack. How are referrals going to work when a future participant in the communication may be limited to one IP version, which happens to be the other one than the one used by current participants? It may very well be that apps and protocols need to be changed anyway in order to work with IPv6, or IPv4+IPv6. From owner-multi6@ops.ietf.org Mon Jun 28 12:18:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13789 for ; Mon, 28 Jun 2004 12:18:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Beynf-000EV8-Ba for multi6-data@psg.com; Mon, 28 Jun 2004 16:16:07 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BeynO-000ETd-Tz for multi6@ops.ietf.org; Mon, 28 Jun 2004 16:15:51 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5SGHH2r074586; Mon, 28 Jun 2004 18:17:17 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6A8C89A5-C91E-11D8-B450-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: draft remarks Date: Mon, 28 Jun 2004 18:15:48 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 28-jun-04, at 9:45, Erik Nordmark wrote: >> 1.1 I think the assumption that an attacker can do everything is >> dangerous, as this isn't a typical capability that an attacker would >> have. It's much more common that an attacker can just monitor, or >> monitor and inject but not block. > I don't have a problem adding a caveat about this in 1.1, but I'm > trying > to understand the cases that you are thinking off. Many networks and especially network elements such as switches today have monitoring facilities. Those work only in one direction, so inserting or blocking traffic can't be facilitated. Then there are wireless networks that are often easy to eavesdrop on. Maybe... > the attacker can also employ ARP/ND spoofing to get access to the > packet flow which allows blocking as well. I suppose. But hopefully SEND will do something about that... >> 2- ULP I think that the definition of ULP clashes with other uses of >> the term, where it is used as "anything above the network layer" or >> "anything above the layer under discussion". The current definition is >> largely the same as "transport layer" if we ignore some more esoteric >> protocols that run on top of IP (such as ICMP) which are special cases >> with regard to multihoming anyway. > I see the definition has "immediately above IP" which actually wasn't > the > intent. The intent was anything "above the network layer". If I say > "any layer > above IP" and add some words about applications would that correct > things? IIRC, that is pretty much what it says now. My objection was that people use ULP more in the sense "anything above the layer under discussion", so your definition would be contrary to popular use. >> Re 3.4: I think it would be possible to mitigate many of the problems >> here by including a periodic state refresh and disallowing adding new >> locators when the original address which has been "validated" using >> return routability is no longer reachable. > I think preventing 3rd party flooding attacks doesn't have to be very > complicated. But are you proposing that a node could send to a locator > without having any assurance that the peer is in fact present at > that locator i.e. without any form of RR check? No, that's not what I was saying. The trouble is that someone can redirect. Periodically refreshing state means that an attacker must impersonate the actual correspondent for a considerable amount of time rather than just fire off something quickly. Obviously when a rehoming event occurs this can no longer happen, so then we no longer allow new locators to be added to the originally negotiated set. At some point there is an RR check for all locators of course. >> 4.3 can be addressed by reflecting the original address back so if the >> negotiation is corrupted by an attacker at least there is a way to >> trace this back part of the way. > Are you commenting on the first paragraph of 4.3? Not so much commenting on the text as discussing the issue. > The more specific details in 4.3.1 and 4.3.2 seems to indicate to me > that you actually need to verify that the peer is present at the > claimed > locator. Ok, then saying "I'm doing this because x.x.x.x asked me to" is superfluous. >> About 5: a good start would be to make a split between the state for >> incoming and outgoing sessions. > But isn't that hard for UDP, when the kernel stack doesn't explicitly > know who started the communication? I'm still not convinced that the kernel wouldn't know this, but that's not the issue as the MH layer knows at least something relevant: if there is no state and we want to send data, we must create it so we are initiating. >> Having to do work per session may not >> be so bad if there is a way to quickly sync up with the state that's >> already there for older sessions. Both hosts would then know they're >> still talking to the same correspondent. If this fails (maybe >> legitimate loss of state due to timeout) they can fall back to a full >> session initialization. > But wouldn't such an ability to securely resume a previous session > require that some state is retained from that session i.e. the session > state isn't really removed? How would this be different than just > keeping all the session state? In either case there would be some > timeout > or other garbage collection trigger to remove the state I think. I'm not so much considering resuming sessions (which I don't think transport protocols do anyway) as creating new sessions that are similar as existing or very recently expired ones, think HTTP with one HTML page and 30 images, making for 31 sessions. This would be soft state: if it's there, try to use it, if not or if the other side says "huh?", do a regular init. So this would be something like "we do multihoming. wanna clone mh state that already exists for the session defined by <...>?". The answer would then be either "..." (no multihoming, strange as they did it earlier), "sure thing" (state is there and can be reused) or "we do multihoming, and this is how we want to handle this session..." (state lost or not reusable for some reason). >> Maybe a stupid idea, but would it be useful to have some mechanism to >> discover insecure links? A simple way to do this would be blocking >> (initial) multi6 packets on such links so initiating multihoming >> negotiations over such unsafe links which may lead to later >> redirection >> attacks becomes impossible. > Apart from the policy question, where different hosts might consider > different > things "secure" vs. "not secure", would it be possible to make any form > of automatic detection of anything but the link attached to the host? One way would be a hop-by-hop option that routers pick up on and modify. Another would be to simply filter a certain protocol and port in insecure networks and assume that any link that doesn't allow those packets through is less secure. From owner-multi6@ops.ietf.org Mon Jun 28 13:31:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17704 for ; Mon, 28 Jun 2004 13:31:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bezwb-000MTH-Ea for multi6-data@psg.com; Mon, 28 Jun 2004 17:29:25 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BezwJ-000MRo-MX for multi6@ops.ietf.org; Mon, 28 Jun 2004 17:29:07 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CE31A39E0C; Mon, 28 Jun 2004 19:29:06 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id BC0DB39DF1; Mon, 28 Jun 2004 19:29:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: marcelo bagnulo braun Subject: cb64 Date: Mon, 28 Jun 2004 19:30:03 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Erik, I have been re reading the cb64 draft, and i was wondering about the fact that the IID is independent of the prefix. This was discarded in SeND AFAIK in order to prevent dictionary attacks. Do you think that cb64 should adopt a similar protection against these attacks? In this case, the iid would differ among locators, and probably it would be needed to change the id used. Perhaps the id could be the public key rather than its hash (as in hip) I don't know how much this change would affect the defined protocol. In particular you would need to exchange the public key beforehand, which is not currently required. this would add overhead when no additional locator is needed, i am afraid. Regards, marcelo From owner-multi6@ops.ietf.org Mon Jun 28 13:32:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17802 for ; Mon, 28 Jun 2004 13:32:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bezxv-000Me0-Fe for multi6-data@psg.com; Mon, 28 Jun 2004 17:30:47 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BezxN-000MZH-SC for multi6@ops.ietf.org; Mon, 28 Jun 2004 17:30:14 +0000 Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5SHTIJ22706; Mon, 28 Jun 2004 10:29:18 -0700 (PDT) Message-ID: <40E0556D.8070807@isi.edu> Date: Mon, 28 Jun 2004 10:29:17 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo braun CC: Erik Nordmark , multi6@ops.ietf.org, Brian E Carpenter , Iljitsch van Beijnum Subject: Re: identity persistence and comparison issues References: <40DB743C.8060005@isi.edu> <34CB9FE4-C683-11D8-97AE-000D93ACD0FE@ing.uc3m.es> <40DC5165.4070900@zurich.ibm.com> <40DCD854.1020904@isi.edu> <0D578C32-C75B-11D8-97AE-000D93ACD0FE@ing.uc3m.es> In-Reply-To: <0D578C32-C75B-11D8-97AE-000D93ACD0FE@ing.uc3m.es> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig710298EBE58D7FD57EF00478" Content-Transfer-Encoding: 8bit X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig710298EBE58D7FD57EF00478 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit marcelo bagnulo braun wrote: > > El 26/06/2004, a las 3:58, Joe Touch escribió: > >> >> >> Brian E Carpenter wrote: >> >>> marcelo bagnulo braun wrote: >> >> ... >> >>>>> The endpoints are the only place that can or should know about >>>>> whether they change. >>> >>> This is a purist view of the Internet we used to have when RFC 1958 >>> was written... the current reality (RFC 2775) is that all these >>> problems call for soft state solutions, that can be garbage collected >>> as Marcelo says, and recreated if they are prematurely lost. >> >> >> Soft state elsewhere is an optimization that relies on hard state at >> the endpoints for its recovery and recreation anyway. I.e., I don't >> see yours and Marcelo's views as inconsistent. >> > > One problem is that if the endpoints are incapable of obtaining the > locators associated with a given identifier (as in HIP), it is > impossible for the endpoints to recover the lost state, so perhaps > having a mechanism for mapping id to locators is a must? That is one of my concerns... Joe > > regards, marcelo > > > >>> (The tragedy of NATs is that they can't do the second bit reliably, >>> and multi6 needs to avoid that problem.) >>> Brian --------------enig710298EBE58D7FD57EF00478 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA4FVxE5f5cImnZrsRAvE1AJ9KOMQv6jGiyuO25OMmAwt0HXCvHgCfWcsY SFzBP2AReB6LINrxRAt+Zhk= =Mbpy -----END PGP SIGNATURE----- --------------enig710298EBE58D7FD57EF00478-- From owner-multi6@ops.ietf.org Mon Jun 28 15:38:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25994 for ; Mon, 28 Jun 2004 15:38:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bf1vm-000ByK-1G for multi6-data@psg.com; Mon, 28 Jun 2004 19:36:42 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bf1vV-000Bvw-Gn for multi6@ops.ietf.org; Mon, 28 Jun 2004 19:36:25 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25897; Mon, 28 Jun 2004 15:36:22 -0400 (EDT) Message-Id: <200406281936.PAA25897@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-multi6-things-to-think-about-00.txt Date: Mon, 28 Jun 2004 15:36:22 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Multihoming in IPv6 Working Group of the IETF. Title : Things MULTI6 Developers should think about Author(s) : E. Lear Filename : draft-ietf-multi6-things-to-think-about-00.txt Pages : 19 Date : 2004-6-25 This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6. The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution either. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multi6-things-to-think-about-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-multi6-things-to-think-about-00.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-multi6-things-to-think-about-00.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: <2004-6-28151344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-multi6-things-to-think-about-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-multi6-things-to-think-about-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-28151344.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Tue Jun 29 02:48:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26078 for ; Tue, 29 Jun 2004 02:48:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfCNJ-0008Xt-UQ for multi6-data@psg.com; Tue, 29 Jun 2004 06:45:49 +0000 Received: from [131.160.193.2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfCNC-0008X1-AM for multi6@ops.ietf.org; Tue, 29 Jun 2004 06:45:42 +0000 Received: from nomadiclab.com (n45.nomadiclab.com [131.160.193.45]) by n2.nomadiclab.com (Postfix) with ESMTP id 112A221309E; Tue, 29 Jun 2004 09:45:41 +0300 (EEST) Message-ID: <40E10FDB.5010706@nomadiclab.com> Date: Tue, 29 Jun 2004 09:44:43 +0300 From: Jukka Ylitalo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo braun Cc: Multi6 List , Erik Nordmark Subject: Re: about Wedgelayer 3.5 / Fat IP approaches References: <40DFD22A.8080705@nomadiclab.com> <19CD73A6-C8EC-11D8-97AE-000D93ACD0FE@it.uc3m.es> <40DFF563.5020809@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo braun wrote: >> Next, I try to replace the current WIMP identifiers with NOID kind of >> AIDs >> for both end-points; in the next WIMP I-D. The ephemeral context >> identifiers together >> with hash chains would then be used only to identify the context. >> Basically, they would >> serve the same purpose as the purpose built-keys for initiators. >> That is, epheral context identifiers could be used to prevent >> attackers from stealing >> a context. (I'm trying to figure out how to bind a specific >> application identifier to >> a specific context.) >> > > I guess that we should see the details before commenting but in > abstract terms, my concern would be: > Thanks for your valuable comments Marcelo and Erik. We are currently working on the details, and I will get back to the issue later in the form of WIMP-01. > > > ...something else. NOID uses the DNS, HIP uses the crypto nature of > its ids, what would be the mechanisms here for this? > That is a very good question, and Erik already gave a short answer to this. We just have to figure out what are security implications of this and if this works, how it works. br, Jukka > > regards, marcelo > From owner-multi6@ops.ietf.org Tue Jun 29 03:15:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27264 for ; Tue, 29 Jun 2004 03:15:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfCot-000D7f-Kd for multi6-data@psg.com; Tue, 29 Jun 2004 07:14:19 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfCof-000D3Q-Pz for multi6@ops.ietf.org; Tue, 29 Jun 2004 07:14:07 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id E334948426F for ; Tue, 29 Jun 2004 09:14:11 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Draft interim meeting minutes Date: Tue, 29 Jun 2004 09:14:01 +0200 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, please find the draft interim meeting minutes below. Please mail comments or corrections by July 7th. Neither me or Brian can find a copy of Eliot's presentation. We have asked him for a copy and will publish it on http://ops.ietf.org/multi6/interim-04/ as soon as we have it. I will let the list know when it's there as well. kurtis & Brian Minutes of meeting from Multi6 interim meeting ============================================== Date: 2004-06-14 Place: Santa Monica, Loews Hotel Agenda: 1. IPR reminder, logistics, agenda bashing (co-chairs, 10 min.) 2. Charter review (co-chairs, 5 min.) http://www.ietf.org/html.charters/multi6-charter.html 3. Review "Things to think about" draft (Eliot Lear, 45 min.) http://www.ietf.org/internet-drafts/draft-lear-multi6-things-to-think- about-03.txt 4. Review threats draft (Erik Nordmark, 45 min.) http://www.ietf.org/internet-drafts/draft-nordmark-multi6-threats - -01.txt 5. Review + discuss future Architecture draft (Geoff Huston by phone, co-chairs, 2 hours) http://www.ietf.org/internet-drafts/draft-huston-multi6-architectures - -00.txt 6. Open discussion on the impact of various categories of solutions (co-chairs, 1 hour) 7. Conclusions of meeting and where to move from here. Minutes of meeting: Jens Kristian Kjaergaard with support from John Loughney, Kurt Erik Lindqvist, Brian Carpenter and the Jabber scribes in the form of Iljitsch van Beijnum, Bill Fenner and Joe Touch. Minutes edited by Kurt Erik Lindqvist and Brian Carpenter. Slides used as input can be found at http://ops.ietf.org/multi6 Jabber log at http://www.xmpp.org/ietf-logs/multi6@ietf.xmpp.org/2004-06-14.html Audio/video archive at http://www.muada.com/multi6streaming2.php For A/V streaming see http://ops.ietf.org/lists/multi6/multi6.2004/msg00902.html Attendees : Kurtis Lindqvist, kurtis@kurtis.pp.se Jens Kjaergaard, jens.k.kjaargaard@ericsson.com John Loughney, john.loughney@nokia.com Thomas Narten, narten@us.ibm.com Michael O'Neil, mjo@arin.net Erik Nordmark, nordmark@sun.com Dave Crocker, crocker@brandenburg.com Roy Brabson, rbrabson@us.ibm.com Eliot Lear, lear@cisco.com Joe Touch, touch@isi.edu Mikael Lind, mikael.lind@teliasonera.com Josh Chao, hcc@mail.ndhu.edu.tw Qing Li, qing.li@bluecont.com Jean-Francois Tremblay, tremblay@hexago.com Tomohiro Fujisaki, fujisaki.tomohiro@lab.ntt.co.jp Jim Bound, jim.bound@hp.com Yanick Pouffary, yanick.pouffary@hp.com Jordi Palet, jordi.palet@consultintel.es Brian Carpenter, brc@zurich.ibm.com David Kessens, david.kessens@nokia.com Iljitsch van Beijnum, iljitsch@muada.com Marcelo Bagnulo, marcelo@ing.uc3m.es Jukka Ylitalo, jukka@nomadiclab.com Aaron Falk, falk@isi.edu Bill Fenner, fenner@research.att.com Joe Touch, touch@isi.edu Jeff Barrows, jeff@barrows.net Chris Christou, christou-chris@bah.com Ali Karimi, aki.karimi@ieee.org 1. IPR reminder, logistics, agenda bashing (co-chairs, 10 min.) =============================================================== Brian Carpenter commented on the intention of the meeting agenda and briefly addressed the alternative schedule put forward by Iljitsch van Beijnum on the multi6 mailinglist. A set of questions were prepared by Kurt Erik Lindqvist (Kurtis) and Brian Carpenter for agenda item 6. Brian Carpenter gave a reminder of the IETF IPR rules as updated by RFC3667 and RFC3668 and encouraged people to follow IETF etiquette by: - reading the drafts before commenting - taking turns at the microphone - signing the blue (white) sheet - noting that meeting minutes will be public Iljitsch van Beijnum encouraged us to complete one issue before going to the next during the discussion. 2. Charter review (co-chairs, 5 min.) ===================================== Brian Carpenter (BC) reviewed the current working group charter defined in http://www.ietf.org/html.charters/multi6-charter.html. Brian Carpenter noted that the WG has only produced RFC3582, that has (possibly conflicting) goals that aren't strict requirements. The "Multihoming in IPv4" draft has expired and kurtis intends to issue a revised version before the IETF San Diego meeting. Aaron Falk(AF): We have received some other documents, but not evaluating, and not all drafts seem to be listed. BC: There are to many to list them all Kurtis: There is a list of all multi6 related drafts at http://ops.ietf.org/multi6 - if there are errors, tell kurtis. Someone: The working group webpage should be updated with a link to this page. BC: Yes, we will ask the secretariat to update the page [Note added after the meeting: this has been done.] AF: There is some important charter stuff that is not in the new charter BC: We are not chartered to actually work on solutions, and when a WG later is, it might not be this one or even in management/ops Area. 3. Review "Things to think about" draft (Eliot Lear, 45 min.) ============================================================= This agenda item was a review of: http://www.ietf.org/internet-drafts/draft-lear-multi6-things-to-think- about-03.txt Elliot Lear (EL) presented the changes and open issues. Slides at ???????????????????????????? EL: Not very many updates since last meeting, should not take full 45 minutes. Thanks to Marcelo and Pekka. EL: First change, if using shim layer aproach. Is fragmentation done above or below shim layer? And can you piggyback on existing fragmentation? If you can establish a context while doing communicaiton this could reduce latency, and this would be very valuable. Saving roundtrips is good, especially on "call" setup. IF you are doing the shim on top of fragmentation that can be troublesome, especially with UDP. Joe Touch(JT): "Call" setup? I am at the IETF. Is roundtrip saving a specific issue for multi6? Seems to be specifically tailored to a telephony type of environment. Why save roundtrips if noone else in the stack is doing it? EL: A phone regulatory limitation JT: That is the point, IP is best effort. This is a red herring. EL: This is not a requirements draft. If you address this it is a nice thing, but doesn't disqualify solutions that don't meet this. BC: Hard to dismiss phone requirements. Disagrees with Joe, the world is changing whether we like it or not. Dave Crocker(DC): Sometimes we can replace bad requirement with a good one. You don't delta one view of the world to another, replace yes but not delta. Latency and roundtrip counts not just for call setup in a telephony environment. EL: No phone vs internet debate, latency counts. Better not to use these examples. Margaret Wasserman (throught Jabber, MW): Are the presenations on-line? BC: No [Note added after the meeting: Bill Fenner contrived to upload most of the slides to a temporary site via GPRS!] It was agreed to avoid the phone terminology and move on. EL: I added the MPLS-TE part on the request of Pekka Savola. Iljitsch van Beijnum (IvB): Why layer2 stuff? We are working on layer three here. EL: Right, but there may be some subtle interactions. Not sure. Traffic Engineering implications of multi6 cannot be ruled out, which makes it a valid item in a things-to-consider draft. Few of the new requirements were my idea. The list on the screen are changes made in this version and has come as feedback from others. Someone: How does your solution interact with DNS caching semantics? EL: Randy in the meeting in Minneapolis pushed for operational concerns document. KL: General comment. With DNSSEC there seems to be circular dependencies that we might be careful of as well. But others here know more about this than I do. EL: Yes, that is Margaret's pet-peeve, circular dependencies were already in the first draft. Example was what if the DNS server is multihomed? It would be could if DNS servers could avail themselves of multi6. EL: Another new issue, impact on in/egress filtering. EL: A word about applications. Eihter the solution odes not require any changes, in which case the application only deals with IP addresses, or things that look like IP addresses. Or the changes are hopefully clearly documented and relatively simple code fragment diffs might be nice. HIP makes IP addresses opaque as it fits in 128 bits but it doesn't really look like a regular one, may be ok for some apps not for others. EL: Logging issues aren't really mentioned. EL: If you make addresses opaque to applicaitons, how do applications keep track of who they're talking to? We may need to theorize but not actually create an API. AF: Random thoguht. If you are debugging, I can ping an IP address, may want to ping an identity? EL: Yes, interesting. Two pices of information. Ping-like, traceroute-like. I.e see which addresses are involved in reaching a certain identity. DC: Important, I was considerably dismayed as an apps guy. I would like to see code diffs for apache to implement locator/identifier split. BC: maybe push to area-directors? Maybe imposing that *nothing* changes is hard, but should be careful with requiring to change applications. There was much pain in apps land when the basic IPv6 changes where made to the stack. [Editing note: did I say stack? Surely I meant socket. - BC] TN: Be careful about ruling out of scope. Useful to list stuff, but in the end make tradeoffs. This implies API must use addresses. BC: We clearly have an action item to get handle on boundary conditions. KL: Do we want it in this document? BC: Probably not. We should talk to application ADs. And we hope our AD is listening... John Loughney (JL): I support Brian. Not talk aout specific applications, but about things like callbacks ans so on. Solutions should consider this. Someone: We need several lists. We need to know wheter identifiers change or not, whole bunch of stuff. We need to collect it, but not neccessarily right now. EL: Note that this talk is a diff. There are other referral issues in the draft already. EL: Moving on, security. Does your solution introduce time-based attacks that were not previously possible? Add referrence to threats draft. We'd like to follow hippocratic oath: first do no harm. I have just asked questions, but now rather spend time on solutions. IvB: I am concerned that solutions may create strong dependency of the Internet on DNS. Application stuff was fun, but what about DNS? Today I can do stuff without DNS. May not be able to in the future, regardless of the circular stuff? EL: Please provide text. EL: And I am done. BC: Do people in this room want to adopt this document as a WG document? We can decide if we want to publish it as an RFC in the future. The meeting unanimously raised its hands to adopt the document as a WG document. BC: This has to be verified on the list, and we will later decide if we will freeze the draft. 4. Review threats draft (Erik Nordmark, 45 min.) ================================== This agenda item was a review of: http://www.ietf.org/internet-drafts/draft-nordmark-multi6-threats-01.txt Erik Nordmark presented the draft according to input in presentation: http://ops.ietf.org/multi6/interim-04/multi6-interim-threats.pdf JL: One concern about new identifier space. What's the role of authentication and authorization for that space? Do we need to AAA that ID and how does that relate to the IP address? Does this bring up any new security threats? EN: We are assuming that an ID at some level, be it an identifier or locator can speak for itself at some point. The basic concern is proving ownership of the id. Inherently you're authorized to speak for yourself, you can go further with authorization, especially authorization to send a locator to avoid DoS. I don't know wheter it's "ownership" notion or "authorization" - "ownership" is simpler. JL: Authorization can live higher. We need to be careful with implying too much about identifier layer. Final note, what about binding between ID/Loc? Would it be possible that you're authorized on one IP address but if you change to a different connection how do you get your identifier still valid for that new connection? EN: It might make sense to come up with more context - there may be some intro material for the draft. TN: Using authorization words helps clarify who is being authorized, clarify e.g. address authorization/ownership. TN: When to publish vs. when to sit on doc. If the WG thinks they're done, it might be useful to push it through IESG to get the IESG review - not a crime to publish an RFC and then update it a year later. DC: I suggest we distinguish between IPv4/TCP today (i.e., threats that we tolerate) vs. ones we are creating with multi6 vs. something that's an opportunity to "improve" the current infrastructure since we're changing things already. Some of what I've heard today sound a whole like trying to "fix the Internet" EN: I'm just trying to make sure we understand where we are today with the IPv4 Internet. DC: Yes, just distinguish between what threats are new and what are part of the existing world. BC: It's ok to say "this is a threat and we're not going to fix it". JL: Make sure we put the limits as to what we're going to authorize/authenticate. The use of address as authorization has happened; how do we identify but not solve fixes to this? EN: pointed out that although the concepts of on-path and off-path attackers are well understood potential dynamic or pass-by on-path attackers needs further considerations. EN: Appendix B contains input to the security analysis of some of the proposals. Is this the appropriate place? BC: Suggest to leave "as is" and review in 6 months. Elliot Lear mentioned that mobility related threats are new compared to existing treat scenarios. BC: Do we think the WG should accept Erik's draft as a WG draft? The draft was accepted as a working group draft with most of the room for, some abstains, and no against. To be confirmed by the WG on the list. 5. Review + discuss future Architecture draft (Geoff Huston by phone, co-chairs, 2 hours) ================================================================ This agenda item was a review of: http://www.ietf.org/internet-drafts/draft-nordmark-multi6- architectures-00.txt Geoff Huston presented "Architectural approaches to Multi-Homing for IPv6" remotely on phone from Australia. Slides at http://ops.ietf.org/multi6/interim-04/2004-06-10-multi6-arch.ppt Geoff Huston (GH): This is an idividual submission I hope will be accepted by the working group. GH: If you can get PI space from your RIR you can have multihoming, but this isn't easy especially if you're small. So then use a more specific of PA space. This is often a backup solution, no good load balancing. GH: The issue is that if you want a solution that can work for decades you can't assume the number of mulithomers is going to be small, there may be millions of other assumption we have to make: we don't know the scaling issues with current routing, both protocols and routers we have now. We can use routing approach for multihoming but it may not scale adequately. The question is if there is an alternative approach. GH: Take 2 address blocks, one from each provider. Communication depends on reachability and policy. Can I do load balancing OR primary/backup configuration? Generic problem: local host in multihomed site, ISPs a and b, internet cloud, remote host. GH: There are a number of things to be aware of. GH: 1. Two means more than one, can be several but two is the minimum. GH: 2. First hop must be different for first hop, don't know about the rest and trying to know this isn't a goal. Second thing to know: this isn't mobility, homeless or otherwise. I.e there always is a starting position of assured connectivity. Additional connectivity may be established dynamically. So if you bring up isp c when a session is already running over a and or b, adding c to the session should be ok. GH: Functional goals, RFC3582 enumerates them. They are not requirements, but goals. You can't meet all objectives all the time, also from the other drafts discussed earlier. RFC3582 gives you a list of 10 items: redundancy load sharing, traffic engineering, policy, simplicity, etc. When grouping points some are about routing, some are not. Last but not least, names/endpoints, stuff in the dns issue, bootstrapping problem re. legacy compatibility, you must be reachable through a FQDN. EL: One quick point: the questions addressed are all appropriate but the organization of the document could be better. GH: Four generic approaches: 1. Route each M-H site IPv4 approach 2. Introduce ?Identity? into the protocol exchange 2.1 Insert a new element in the protocol stack New synchronization element to exchange id/locator binding 2.2 Modify the Transport or IP layer of the protocol stack Perform id/locator mapping within an existing protocol element 2.3 Modify the behaviour of the host/site exit router interaction Modified forwarding architecture coupled with distributed state of identity / locator binding JL: Other WG is working on path signaling. Alison Mankin (Through Jabber, AM): My point is that multihoming can't include all this functionality per se within it. IvB: Traffic engineering is an actual requirement. People aren't going to pay for bandwidth that they will use 1 per cent of the time. GH: Slide 7. I call myself by my identifier, you call me by my locator. Have identity stuff as discrete element or do it in an existing protocol element and sync up at the same time as this element. GH: Final option (of the 4): can modify behaviour of the host site exit router interaction: site exit router changes your stuff with or without host's knowledge. GH: Slide 8. Multihoming via routing. Ultimately, routing each site removes structural hierarchy from interdomain system. 10^7 is taken as a meassurement of the number of sites required to be supported. We don't think this scales. GH: Slide 9. If you can't do it in routing you have to do the split; there is no other way. The network needs to route the packet based on "where". GH: Slide 10. New protocol element, that have to map somewhere in the stack. We can do this in two places: between ip and transport or between transport and ulp (although nobody proposed this). IvB: I think doing it between transport and ulp is a red herring - how can you do it without reimplementing much of TCP? DC: Geoff I appreciated your point that this is a theoretical point. One of the functional requirements when doing it at session layer, is to maintain what applications thinks is transport context over multiple transport connections. BC: There is at least one proprietary solution that doesn't care about TCP survivability. DC: Transport survivability is an issue if doing it at the session layer. GH: I agree. I will put in more text for completeness. GH: Slide 11. Other way to do it: change protocol element so it's done as part as normal operation of that element (transport or ip). Can have set of locators that work as identifier, or alter the ip protocol to support ip-in-ip structures that distinguish between current-locator-address and persistent-locator-address , ie. mipv6. GH: Slide 12. Modified host / router interaction. May need to do source based routing because isp may do unicast reverse path filtering; a very heavy weight solution compared to the alternative of adding morelocators. BC: Do you disagree with the analysis in the Huitema draft? GH: No. But it's very heavy weight to have to modify all internal-site routers if the behavior of a router depends on location in site, hard to operate/debug. BC: Don't disagree, but Huitema draft says you MUST solve ingress filtering problem. GH: Different solutions here. JT: We do something like this where each host has an internal router, everybody is an exit router. GH: Write it up, as I am not sure I completely understand it. GH: Slide 13. Number of ways to solve site exit problem. First, if you only want the ser (site exit router) to route and nothing else, (which is probably a good thing to do) then have dmz/anycast group and tunnel to appropriate ser/isp other approach: all internal routers do source address based routing. Third, dangerous, make sers rewrite source addresses. Fourth, modify uRPF so any isp accepts any source locator move on to identifier/locator binding. GH: Slide 14. You want to allow a single session to work over multiple paths over time. One approach: transport protocol establishes session on identity, then *SOMEWHERE* map to locator that's used on the wire. GH: Slide 16. Where do you put the new identity protocol element? Most proposals put this above ip and below fragmentation and ipsec. This makes sense if you want things to happen correctly. BC: Ohta-san made a strong case on the mailing list that this is completely wrong and it must be in transport. Counter-argument? GH: Haven't directly addressed this claim, but I disagree. If you want IP-Sec and fragmentation to work, you need to do dynamic rewriting AFTERwards and map back at receiving side. GH walks through ulp->transport->identity->ip and back at receiver interactions. Identity is explicity there because you need to synchronize both ends. GH: Slide 18. How can you do this? Conventional: each protocol takes a PDU from the previous one, so simply expand packet at each layer. GH: Slide 19. Some approaches have explicitly gone out of band, and there is some benefit here, topology changes don't always happen nicely. This can use timing of topology change rather than application timing. The other way is three way conversation with reference point so two parties sync with a third one. This is a generalization of using dns. GH: Slide 20. "referential". Use a reference to a third party point a a means of peering (e.g. dns identifier rs). GH: Slide 21. Use identity token from protocol address space, or FQDN as identity token. Structured token vs unstructured token. If we use ip address little changes necessary. Use identity tokens lifted from a protocol address space DNS, applications, transport manipulate an address. IP functions on locators. Stack Protocol element performs mapping of FQDN as the identity token. Is this creating a circular dependency? Does this impose unreasonable demands on the properties of the DNS? Structured token. What would be the unique attribute of a novel token space that distinguishes it from the above? Unstructured token. Allows for self-allocation of identity tokens (opportunistic tokens). How to map from identity tokens to locators using a lookup service? Adding straws to back of DNS camel may be dangerous. GH: If you're going to create a new namespace it's either going to look a lot like a dns name or a lot like an address. DC: Keep same namespace as DNS but distinct lookup servie. TN: Running dns on a new port requires serious thought. Is this a place we want to go? DC: I'm not saying we do, just have it on record. GH: Alternatively, take token with no structure at all. It's just a token, not even complete guarantee of uniqueness. This works well, except for mapping. IvB: Is this token per site, or per host? GH: Or per session, per site means some structure. GH: Next slide. Common issues: Picking the "best" source locator. Try them all. Or identity peering protocol to allow the remote end ... GH: Slide 23. Other part is picking best destination locator. Longest match / use each in turn. Iljitsch made point in march: may need to look at pairs of locators. GH: Slide 24. How do you know when to change address? Timeout may take too long. Proposals for heartbeat. Modified transport trigger. Host/router interaction trigger. Application timeframe vs network timeframe. Failure during session startup and failure following session establishement. GH: Slide 25. How do you know a session is completed? What do you need to do to bootstrap? Are there "distinguished locators" that you always need? GH: Next slide. Session persistence. Use home locator. Use locator set. Use new peering based on identity protocol elemenet and allow locators to be associated with the session identity. GH: Slide 27. Identity/locator binding domain. In very restrictive HIP there is a new identity per session. Allowed to bind bindings across sessions? Binding management issues. GH: Slide 28. Bilateral peer applications vs multi-party applications. Applicaton hand-over and referral in session-based identities referral is impossible or rather: extremely challinging. GH: Next slide. Security consideriations. Point to Erik's draft real soon. EN: Back to common issues. Session establishement is common, but termination also. There are two pieces to the security stuff: Keep architectural issues from actual threats. Where we need to do something like your draft for security too. GH: Generic architecture for security hard to do. Vulneratbilities are clear from actual implementations, hard to do based on generic stuff so you'd have to analyse each proposal separately. BC: We decided to keep Erik's security draft and park analysis there until we find another place for it. BC: Do security analysis when number of proposals gets below 30. GH: My suggestions for moving forward: 1 complete proposal survey (appendix). 2. analyse identity properties in further detail. 3. Examine some futher open issues (next slides). 4. Make some tentative conclusions regarding the properties of a robust multihoming approach and a strawman propsal). 5. Submit to WG for adoption as a WG document. BC: Do you want to do one more iteration of the draft as individual before making it a WG document? GH: Yes. Now the open issues: GH: How serious is routing problem re multihoming anyway? Can routing scope be a better solution that complete protocol reengineering? Are there other approaches here to managing the inflation rate? Betting on routing isn't necessarily bad, it just has risks. Open questions: "Are you doing all of these changes JUST for multihomming"? The issue is that it's a big fundamental problem, more general than multihoming perception could be that this is solution overkill. We have to distribute identity prefixes also structured space management has serious overhead. You can't just select your own identity, so can we use something that already exists? DC: May want to mention origin of first two points: "strategic marketing": not getting much for what you're doing. Second we should worry about operational impact. GH: Second one is very important. KL: Yes, there will be overhead but we have that today too. GH: Yes, someone said for domain names this is terrible. BC: Ergo: do not involve ICANN. EN: Why need structured space? To make lookup scale, and to guarantee uniqueness. We can probably make top not administrative. So structured space != someone owns the root. GH: Slide 33. Applications and id/loc is a self reference within an application the identity value? If so, then can opportunistic id values be used in this context? JT: Questions about what you can and can't do with identifiers GH: Slide 34. Structured space heavy weight solution. Unstructured space has referral issues, potential vulnerability to attack if using ip addresses in referrals, still the existing overloading... GH: Next slide. Proposed next steps. I intend to have a new version within a few weeks, before the cutoff for San Diego. Want to do more work on survey, more notes on routing, steps 1, 2 and 3, but not 4 (see earlier). KL: What if we limit the number of solutions later today? GH: I wanted to capture survey in longer-lived document. The architecture draft is kept as an individual submission by Geoff until point 1. + 2. + 3. in the next step list is done. Hopefully this could be settled within the next couple of weeks. 6. Open discussion on the impact of various categories of solutions (co-chairs, 1 hour) =============================================================== The objective of this agenda item was to structure the more than 30 proposals addressing IPv6 multihoming. For this Brian Carpenter used his slides at http://ops.ietf.org/multi6/interim-04/interim-agenda.ppt (start at slide 8). BC: Does Geoff's draft cover the right stuff? EL: It might cover too much. I don't know if it is ready for RFC publication, but it would be ready for WG document status. It doesn't appear to miss anything substantial. IvB: I sent in a list of comments when he first published it, didn't check if they were addressed in the -01; One thing that was missing in the previous version is the issue of initiating new sessions when there has been an outage - the -00 talked mostly about keeping existing sessions running. Should be explicit that this is important. GH : There is no -01 yet - these comments will be integrated. JL: Geoff's draft seems quite complete; I'd like to see reducing some of the scope; It especially struck me that some of the common things for multihoming are common in general. So not specific to multihimoning. We should start scoping out what's more explicitly multi6. BC: Geoff's draft or another draft? JL: I'd like to see Geoff's start to scope things at least say that things are not just a multihoming issue. GH : Common in general for id/ocator split or common in general in some other way? I'm still unsure - IF you head down the id/locator split then there are a set of issues. JL: I think his draft captures commonality in ID/Locator split, that's reasonable; some are more general in the general sense -- like detecting loss of connectivity, detecting presence of connectivity BC: One of the drafts that v6ops is not currently considering pertains to how you find v6 connectivity when randomly attaching to the network; there's some commonality there to finding some connectivity in multihoming. BC: Conclusion: not much missing; scoping issue: make it explicit what things are intrinsically part of multihoming and what is more general. BC: Slide: "Some questions (2)" Is modifying all transport layers to deal with multihoming realistic? Are all transport layers equal for mh? Will applications in general deal with mh issues? Do we believe that any applications will deal with mh issues? TN: that means modifying every single UDP-using application. EL: With TCP and SCTP, you know the start and end; state is well-defined and maintained below application. Now with UDP you need to not only maintain that below state but also names/id/loc/etc JT: I would phrase 1st Q. differently: I don't think it makes sense for a transp layer to know what multihoming means - but it makes sense for them to know an identifier is. I may want to rewrite transport layers once to abstract ID, but not deal with multiple IDs. IvB: The socket layer might know when communications stop and start. Don't create an artificial dichotomy between modifying all transports and not modifying any transports; Could modify some. BC: "Satirically", "tell everyone to use SCTP and you're done". IvB: Transport based on UDP are done in applications; changing applications takes forever; most applications use TCP; you could implement a change in TCP and just do something to UDP that keeps them running but doesn't necessarily give all the gains. EN: What's the need for modifying things at the transport layer? Transport do everything wrt multihoming? Transport is aware that there are multiple paths to relearn e.g. congestion but not perform any multihoming decisions itself. Can you give *some* benefit to unmodified transports, then can you put something into the transport to make them work better? BC: E.g. ECN if the path changes EN: Could say that we're only going to worry about TCP, but even saying therefore a session from multihoming perspective is only TCP, that might not scale well for short sessions. BC: Or media streaming. EN: So part of what we're asking about is connection-oriented vs. UDP BC: and DCCP GH : Media streaming === DCCP is the direction - yes - so we may be talking TCP and DCCP here. EL: We're hearing about what you can and can't touch - I don't think we should hold the application layer to be sacrosanct. Misuse of IP address in applications? Suggest 3 levels: modify IP layer; connection-oriented; application layer? Say to application providers "If you want to take advantage of this, you need to add a call or two or understand ID/Locator". BC: I'm hearing people say that the big bullets are "no" and small are "yes". EL: Perhaps some apps don't care to use the new API; could have shim library. BC: Implying new socket calls as a result. EL: Potentially. TN: 1st bullet is wrong question to ask: it's not a yes/no question, since it depends on what the change is. KL: Can a non-modified application or transport layer take any advantage of the improved underlying network? BC: That's never been a requirement. KL: We're close to going down that rathole. Someone: What about ipsec tunnels? BC: That was covered in Geoff's presentation - location of shim decides whether fragmentation or ipsec works. BC: Whole solution in transport isn't very popular with those in this room; part of the solution could go in the transport. IvB: There are 2 different ways unmodified apps could take advantage of multihoming: 1. If full ID/Locator split, apps see IDs, big problem is mapping service. 2. If something like NOID, there are IP addresses that must be reachable in the app that filter through the API; the lower layers probably can't change e.g. a nonworking dest addr for a new session attempt to a working dest addr since they don't know the working addresses, can change source address because apps usually don't specify source, can do tricks when failure in the middle of a session. BC: Line closed for this slide. JT: Re IP-Sec: Worth categorizing, e.g. IKE looks like an application. Protocol caring about address used for routing, it cares in the way that a transport protocol would, so think of it in the same way. Conclusion on this slide: questions aren't quite properly phrased. Probably will be some implications to transport layers even though we don't put the solution in the transport layer. Same is probably true of [sophisticated] applications. BC: Now on slide 10 - "Some questions (3)" Is it reasonable to assume that socket state can include mh state? Or does the necessary state have to be dissociated from sockets? Can the IP layer accurately decide when to forget mh state? Does it matter if mh state stays too long? JT: I don't think it's appropriate to say "Socket" here. As far as portocols are concerned that's an application layer. I'm not saying we shouldn't talk about sockets; last slide talked about application layer, sockets aren't magically different. Sockets are a particular implementation of an application layer. BC: Socket state is implementation-specific state that contains all the magic protocol state; why is that application layer? GH : The second bullet makes sense to me as a question. TN: Maybe another not well-formed question - more like "Will applications have or need access to the multihoming state"? GH : And the answer appears to me to be 'no' - it would be preferable for transport to signal session state to the id/loc mapping. JT: Socket layer *is* the application. KL: There has been this discussion & we have the general question - upper-layer hints? -> clearly modification of the socket interface, if applications help manage the state. TN: Maybe real issue again is what info needs to go up, how high up, what needs to go down, how far down? BC: And what needs to be stored? Take noid - somewhere you have to keep a list of locators that go with the locator you're using for the ID. Is that kept once per socket, once per host, ...? EN: This is about sharing or reusing data across multiple connections or over time. EN: So that degree of sharing is different than the question that Thomas is asking. IvB: Discussions about a database for id/locator mapping. Aren't we getting ahead of ourselves, how about fundamental stuff like functional decomposition? Then these questions are much easier to answer. JT: Relates to idea of whether IDs have meaning across different hosts or different applications on the same host. If ID has meaning for different apps/sockets on the same host, you might choose to implement it by caching at the application layer. Some of the socket info is application layer, some of it is transport layer. That's part of why socket isn't a good term, be more specific. Qing LI (QL): Socket/application layer info is quite important for proxy appliances - if ID is used for authorization it's important to look it up. EN: On the 2nd bullet: It might depend on other assumptions; if you have a solution that has a seperate new ID space where you might not be able to discover locators from an ID, making sure you don't throw away the state too early might be critical - youc ould have a transport connection to a HIP and you threw away the locators. EN: On the other hand, if you can discover it again e.g. in the noid case, you may discard the state early since you can recreate it. The other question is, does allowing the two ends to forget state independently introduce security implications, if one forgets and the other doesn't? A has forgotten, so I can pretend to be A. DC: We used to have access to one locator. Now we have a pool that go to the "same place". The pool is the state. That's not even a new idea at the IP layer. Routing tables are maintaining this kind of state. I've always been thinking of this as transport question - you're doing routing and state maintenance in multi6; we call it state when it's only on the endpoints but it's not 'state' when it's routing. BC: Page 11: "Some Questions (4)". My questions about routing are much like Geoff's; probably no need to spend much time on this slide. GH : Yep - I had put forward the view that site exit router selection and a reliable mechanism for unicast reverse path filtering were 2 aspects of the same outcome and the second was going to be easier than the first. TN: Another question of level: small change, perhaps. EN: Definitely cannot depend on a change. What about asking the routing protocol for "this path might be flaky"? KL: Do we believe in Moore's law more than we believe in protocols? Do we think it will be enough? BC: And we're clearly not expecting someone to implement BGP 5.5. IvB: it's too bad Geoff isn't here because he would have lots to say on how BGP scales EN: I wasn't trying to propose that routing solve the whole problem, just communicate some bad news. IvB: BGP *does* communicate the bad news. BC: Page 12: Some questions (5): Can we make a functional decomposition, e.g. Component to establish mh session state Component to trigger rehoming Component to choose new address pair Component to execute rehoming Component to delete mh session state BC: This is by no means a proposal, just an example of what we might want to aim at. EN: I think 2 and 3 are easier to seperate out than the others. To what extent is management of session state tied in with informing the other end? It can get hints from various places that can trigger this. JL: Is the point here to ask "should we do a functional decomposition?" BC: "will we have enough info to do functional decomposition?" "should we do so?" "where should we do so?" JL: We have enough to start making the decomposition. if we try to get it complete we may never finish it. Take our best shot and live with it. DC: And now we have 35 proposals and have to combine/transform them into one result. Something like this is fundamental for a space like this. We need a series of narrow-scope evaluations that we can then combine. It leads to some decisions about what might be near-term vs what might be long-term. It's not clear that near-term we can get by with something utterly trivial and do the full thing long-term. BC: I suggest we say "this is a question for the WG in general: whether this approach is fruitful, when we should tackle it". IvB: hard to answer this without some idea of what we're going to select out of the 35 proposals. BC: matrix problem, so I want to get on to Kurt's presentation. IvB: Want to see how many of the 35 we can make disappear before we do this. BC: may find things that have already been proposed, clearly relates to one of these components but not to the others. GH : Working on it. BC: Last slide - "Some questions (6). Can we group proposals into 3 or 4 classes and analyze them against Goals Things to think about Threats Architectural decomposition? First cut at categorization of drafts: Kurtis Lindqvist used his slides at http://ops.ietf.org/multi6/multi6-interim-draft-list.ppt. The adjusted list is at the end of this section. KL: This list of drafts is not random: it is an attempt to categorize them. And not everybody might agree with categorization; I might not even agree with them. I spent the morning in Starbucks drinking way too much coffee; short recap of each draft on this. All on the first page are based around structured addresses, structured address allocation or such. EN: Are you saying 1st list is things that say a single locator/address?. KL: Not necessarily; this is just a list of drafts. KL: 2nd slide: various mobileip-based, rewrite, external rewrite, tunnelling drafts. KL: 3rd slide: transport-layer like sctp, also approaches like 8+8, mast. DC: You're trying to find categories to aggregate these into? I'd think that Geoff's paper describes categories you could use, there should be correlations between this exercise and Geoff's categories. KL: I tried to use Geoff's appendix as a basis. But we are getting to those slides. GH : I think these could be meshed to a single form of categorization KL: Going through slides, listing each type. EN: Trying to understand what "tunnels" mean, since all have some notion of seperate IDs and locators. EN: Packet format on the wire is different, hack that NOID does to not have any extra data could be extended to others; tunnelling could be somewhat eliminated in the same way. Could say we have locators of different flavors: home locator and temporary locators, somewhat like mobileip. To me "tunnel" is not the most important characteristic. GH : Tunnelling for me is where the association is carried in the packet, rather than in held endpoint state. I.e. where you hold the association is a form of categorization IvB: The reason I called my proposal tunnelling was because if you see info that is aggregated away when packets were on the wire and you add it back to the packet it looks like an ordinary tunnel. BC: At one level, there's a functional equivalence between tunelling and implied/shared state, but I think there's a real difference since there's the problem of state synchronization; if the state is in the packets then the problem is not necessarily there. EN: One locator could be an alias for another locator. KL: This is the first category. Does anyone think any of these proposals are going to help us get any further? . BC: We got two questions: do we agree on the categories, and second, can we wipe out a few? JL: Even if we kick out categories we should document them, people tend to come back to the same ideas. KL: It will be in the minutes. TN: Agree with John. Marcelo Bagnulo (MB): I don't understand this category. Singe address solutions in there, multi address solutions, partial solutions... KL: I've already taken out drafts that weren't proposals by themselves. But, yes I agree this is the hard to categorize stuff. TN: It would be good if the authors agree with the categorization. BC: Name should capture common feature. JL: We may want to reuse pieces from these drafts, but not spend too much time. KL: These are the drafts with the least support. TN: But then that is the common feature. Say what part of the draft doomed it. BC: Too much work. EL: Merge everything into one proposal, have groups convince us that their proposal is good. KL: If we take things off this list it doesn't mean they disappear. MB: If you want a category, there are two types, non-pa-compatible (using one address), other category is Ohta-san and his friends. EN: To what degree are those drafts on the list still alive? IvB: Two of those drafts are mine. One is old, forget about it, the other has no support so if you want to drop it for that reason that's ok, but don't tell me it is no good because i still believe in it... David Kessens (DK): Approach authors. We basically have two classes: drafts that are for discussion, these can be quickly killed by talking to the author. Other type is where author strongly believes, this will be more difficult. If people want to keep their stuff we should encourage them to work together with others. Jens Kristian Kjaergaard (JKK): Isn't it more important to agree on the categories? BC: I like the notion of challinging the authors within clases to come up with a unified approach but deadline isn't San Diego. JL: Drop proposals by default rather than keep them around by default. TN: We want to encourage work in promising areas, discourage un-promising. No sense in asking people to come up with a unified proposal for categories we think are no good anyway. "Rough categories and running code". JT: Avoid kicking documents by category, people will want to move KL: categories: - "intermediate systems". MB: Can go, Michel is no longer active. KL: host based, "host signaled". IvB: Naros is valuable and only does one small thing, keep it and not in this category. EN: Naros not on the critical path. KL: Create something for stuff like this - components rather than solutions. EN: Huitema draft is also a component draft. It says the main issue is source address stuff and this is how to solve it. If we can put drafts in multiple categories that would be be appropriate. KL: Don't think I want that. MB: Most proposals deal with a specific issue, we're going to take away parts from more than one to build a solutions. KL: Category "Aliasing" (instead of tunneling) MB: Mobility draft explains why mip can't be used for multihoming, not a solution. AF: I've always thought of hip as a wedge solution, surprised to see it listed as tunnel. JT: I've always seen it as a tunnel KL: Agree. Let's move it to "Fat IP / Wedgelayer 3.5". KL: Category transport solutions. KL: Category wedge layer 3.5 IvB: Geoff made distinction between wedge layer and modifying the network layer but no such distinction here. KL: We're going to have a component category. These aren't things that we either want to kill off or work on, just stuff we want to look at again later. We're down 3 proposals so we're making progress. Do we split the 3.5 category into wedge layer and modifying ip? GH : The distinction was subtle - its was a case of seperate syncronization wit the remote end vs coupled synchronization of state with the transport session. BC: The OSI reference model forgot to be recursive. Implementation as a shim or modify ip comes up later. BC: Margaret Wasserman is supposed to call in, but apparently not right now. KL: I was expecting more discussion. BC: John said that : NSIS people thought NSIS was a solution? JL: NSIS is looking at on-path signalling. NSIS people want to have something to handle multiple paths. BC: NSIS is stil looking at the world as a soft state universe, right? JL: Yes. BC: Unless there is a draft, we have nothing to discuss here. KL: Wedge layer class is now "FAT IP / Wedge layer 3.5". KL: So can we kick out more drafts? Aliasing / tunneling category is going away, remaining draft was ODT, now going to wedge. BC: I suggest that most of the de-aggregated proposals are not to be pursued further. BC: Only a few of these have been presented at the IETF. We still need to take this to the mailing list. BC: . BC: The next steps are obvious and not... BC: The obvious part is we can see a path on how to make progress on 4 drafts which are deliverables. The 4 drafts - threats (Nordmark) ready for San Diego. Things to think about - kept alive somewhat longer. . BC: How multihoming works in IPv4 - much needed; hopefully version ready to discuss in SD. GH : I'll have architecture -01 raady in 1 -2 weeks from now. KL & BC: Will post about categories to mailing list; goal to crystallize discussion and/or omit some. BC: Needs to designate an editor in each area. Margaret Wasserman (MW): Has it been determined which drafts are still alive and which are to be dropped? BC: Sort of; based on the categories. ??: Does this mean a editor for each category or multiples? BC: Single editor per se is premature. KL: Authors should agree to work as a group; can appoint someone from that group. BC: Need point-person ('stuckee') to ensure it all happens. ??: Multiple drafts = multiple 'stuckees'. BC: Chairs won't micromanage. May appoint micromanagers. MW: If we assign editors - one of the authors or neutral? BC: It depends; some may agree, some may not. MW: May go with design team approach. BC: May formalize as design team in the process, but teams aren't agreed as a good process method. IvB: Merge parts of the docs? BC: Hesitatingly agrees, but diplomatically suggests caution. IvB: WG already behind on milestones BC: Those milestones are gone. IvB: We haven't done much technical progress today. Mostly procedural. EL: Takes exception. There weren't 30 proposals 6 mos ago; lots of good recent work, esp. due to chairs. Problem is complex. How do we move forward? Brian and Kurt's proposals are constructive. If authors are really interested in solving problem, they can do 1) work with others, or 2) copy from others. Let's wait for running code; it's the code that matters. BC: Part of the challenge - show us running code. So far, except for SCTP and HIP (only part of soln), no code yet. JL: Creating categories is useful. Also ... if categories are described well, still useful to have outside editor help synthesize. Having Eric do that with noid, etc. was good in this regard. BC: Can this be integrated w/Geoff's doc, esp. w/Margaret's appendix? JL: More concerned with content than process. GH : Yes - that was my understanding. BC: Volunteers to help writing are welcome. BC: What next? DC: Let's spend some time defining layer 3.5 and picking the number. that'll consume time. BC: Thanks to Kurtis for the coffee BC: Thanks Iljitsch for networking, et al. - very IETF style GH : And thank you jabber scribes. KL: Thanks scribes! KL: We're not chartered to come up with a full-fledged protocol; important point to keep in mind. BC: If this weren't hard, it wouldn't take 3 years to get to a solution. That sounds horrible if you're "young and impatient". Problem has been lurking since beginning of IPv6. Jordi Palet: One thing I'm missing is still 'set of use' cases; one discussion on mailing list w/fortune 500 companies. Is Multi6 for residential? Small businesses? It would be useful to consider. BC: I wish those use cases would just appear. We had the same problem with scenarios in NGTRANS before V6OPS. Their scenarios work started a long time ago and has taken approximately forever. These are hard to come up with. We know there are multiple categories. fortune 1000, drive-by's, etc. - there are a bunch. I'm scared of v6ops analogy to launch an effort. It's too hard to get to a conclusion. KL: Difference between multihoming and transition. Load sharing, etc. They're the same for everyone. Transition has more cases. BC: Don't want to commission "use cases doc" BC: Are we done? The outcome of the discussion was a suggestion to split the proposals in the following categories: A. Addressing based * draft-kurtis-multihoming-longprefix-00.txt draft-savola-multi6-asn-pi-01.txt draft-ohta-multihomed-isps-00.txt draft-toyama-multi6-operational-site-multihoming-00.txt draft-ohira-assign-select-e2e-multihome-01.txt draft-van-beijnum-multi6-isp-int-aggr-01.txt * draft-van-beijnum-multi6-2pi1a-00.txt draft-ohira-multi6-multilink-auto-prefix-assign-00.txt draft-teraoka-multi6-lin6-00.txt B. "Intermediate systems" * draft-bagnulo-multi6-mhexthdr-00.txt draft-py-multi6-mhtp-01.txt C. Hostbased draft-huitema-multi6-experiment-00.txt draft-huitema-multi6-hosts-03.txt D. Tunnels E. Transport draft-coene-sctp-multihome-04.txt draft-coene-multi6-sctp-00.txt draft-arifumi-multi6-tlc-fm-00.txt draft-ohta-e2e-multihoming-05.txt draft-ohta-multi6-8plus8-00.txt F. Wedgelayer 3.5 / Fat IP draft-nordmark-multi6-cb64-00.txt draft-nordmark-multi6-noid-01.txt * draft-nordmark-multi6-sim-01.txt draft-ylitalo-multi6-wimp-00.txt draft-crocker-mast-proposal-01.txt draft-nikander-multi6-hip-00.txt draft-van-beijnum-multi6-odt-00.txt G. Components draft-de-launois-multi6-naros-00.txt draft-crocker-celp-00.txt The "Components" class are proposals which contains functional elements, which can be incorporated in the above categories. Way forward: ============ Find and define the categories and group the proposals accordingly. Try to merge the proposals from each category. The initial categorization of the current proposals is above Kurtis and Brian formulates separate mail going to the multi6 mailinglist describing the categories and the split of the current drafts into these categories. After consolidating the list of drafts in each category the next step is to workout a unified proposal for each category, and use this to provide a set of alternative solutions. 7. Conclusions of meeting and where to move from here. ====================================================== 1. Progress on drafts: The "IPv4 multi..." and the "threats draft" should be revised to be ready for working group last call after IETF meeting in San Diego. The "things to think..." draft and the architecture draft need to stay in sync with work on solutions and could be targeting working group last call after the IETF meeting in Washington scheduled for November 2004. 2. Solutions - Issue mail defining the categories (Kurtis + Brian) - Challenge authors (in some cases) - Suggest withdrawal - Designate editor for each category. Editor could be one of the document authors or some moderator. Design team(s) could be used later in the process. The synthesis from each of the categories could eventually go into Geoffs document. It could be good to document the multi6 use cases, but experience from v6ops is not very good. Acknowledgements from the meeting ================================= To Autonomica AB for sponsoring refreshments, meeting room equipment and connectivity. To IPv6 Forum/US IPv6 Task Force for providing meeting room. To Iljitsch van Beijnum for providing network connectivity during the meeting and streaming and recording the meeting. Appendix - additional notes on discussion ========================================= The following is a list of comments and statements issued during the process leading to the above categories. Brian Carpenter's questions at page 8 on in his presentation formed the basis for the discussion. Elliot: Geoff architecture should be sufficient background to continue evaluation. Iljish: Initiating new session after an outage need further work. John Loughney: Functional decomposition should be added to Geoff draft. Otherwise not much missing. Some comments slide 9 Transport needs to know of ID not multi homing. Some modifications are needed for transport layers and applications. Some comments slide 10 The question: "Is it reasonable that socket state can include MH state?" Cannot be answered currently. Some questions slide 11 Brian - most were already addressed by Geoff Thomas - most of the questions depend upon the results - depending upon the bang for your buck. Erik - Maybe should ask what changes are dependent upon, but you may not be able to depend upon the changes to be made. Bill - Supports Thomas' view. Illitsch - Wants to know why we are talking about BGP Brian - this was just an example, not a proposal. Kurtis - do we think it can scale? We are here because it doesn't scale. - - small side discussion on BCP scalability ... Some questions slide 12 can we make a functional decomposition? Erik - points 2&3 may be easy. John - are you proposing that we start a decomposition Brian - Two questions - do we have enough info to make it & should we make it? Dave - I think we need to do this. We need to break it into pieces. Brian - question to the WG - is function decomposition a good direction & when to start the activity? Illitsch - should we start this if we haven't started making a choice on the solution. We should make some of the proposals disappear. Brian - we may find out that some of the proposals relate to one of the pieces. Illitsch - we know some things that we want, but don't agree on all of them. Narrowing down the choices will help. Some questions 13 Can we group proposals into 3 of 4 classes and analyze them? Kurtis has tried to order them according to Geoff's list. list of drafts various solutions based around the structure of the address; various solutions based around mobility, routing, tunneling various solutions based around transport layer solutions Dave - are you trying to find categories to group them. I think Geoff's draft has a grouping, and if the draft is wrong, then it should be updated. Comments on tunnels: Is there a conceptual difference between tunnels and other multi6 solutions? Is tunneling a category on its own? Suggestion for renaming tunnel category to aliasing, representing the cases where on locator may be aliasing another locator. (end of minutes) -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQOEWwaarNKXTPFCVEQJg0ACgqN81/KSugu5ciCpcz7TeVaJS9q4An25C yJoVVqtMkhXM9LWRwK4R+aou =E88P -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jun 29 04:29:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01352 for ; Tue, 29 Jun 2004 04:29:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfDxI-000Msf-QE for multi6-data@psg.com; Tue, 29 Jun 2004 08:27:04 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1Bcjm8-0005tH-6L for multi6@ops.ietf.org; Tue, 22 Jun 2004 11:49:16 +0000 Received: (qmail 76139 invoked by uid 1007); 22 Jun 2004 11:49:12 -0000 Date: Tue, 22 Jun 2004 13:49:12 +0200 From: Gert Doering To: Masataka Ohta Cc: Kurt Erik Lindqvist , address-policy-wg@ripe.net, multi6@ops.ietf.org, Gert Doering , Sascha Luck Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") Message-ID: <20040622114911.GK6204@Space.Net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D8185A.7030900@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, On Tue, Jun 22, 2004 at 08:30:34PM +0900, Masataka Ohta wrote: > >> In favour of *what* to replace it? > > RIR membership. > No. It is proven not to scale. "Proven"? When, where, by whom, based on what data? There are less than 10.000 LIRs in existance today, all RIRs combined. So that would be a maximum of 10.000 routing table entries (if we can manage to keep it at "1 prefix per LIR"). > Does it mean that it is beneficial for you if RIRs have more > power even though it sacrifices ISPs and users of the Internet > by requiring routers with a lot more routing table entries > than necessary? 10.000 routing table entries is something far below the near 140.000 we have today in IPv4. While I'm seriously unhappy with the 140.000 IPv4 routes, it *does* scale up to fairly insane numbers. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-multi6@ops.ietf.org Tue Jun 29 04:29:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01401 for ; Tue, 29 Jun 2004 04:29:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfDxp-000Mux-1g for multi6-data@psg.com; Tue, 29 Jun 2004 08:27:37 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BckUY-000Bad-EG for multi6@ops.ietf.org; Tue, 22 Jun 2004 12:35:11 +0000 Received: (qmail 81795 invoked by uid 1007); 22 Jun 2004 12:35:09 -0000 Date: Tue, 22 Jun 2004 14:35:09 +0200 From: Gert Doering To: Masataka Ohta Cc: Gert Doering , Kurt Erik Lindqvist , address-policy-wg@ripe.net, multi6@ops.ietf.org, Sascha Luck Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") Message-ID: <20040622123509.GT6204@Space.Net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <20040622114911.GK6204@Space.Net> <40D8237D.5020301@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D8237D.5020301@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, On Tue, Jun 22, 2004 at 09:18:05PM +0900, Masataka Ohta wrote: > Gert Doering wrote: > > >>>>In favour of *what* to replace it? > >>> > >>>RIR membership. > >> > >>No. It is proven not to scale. > > > "Proven"? When, where, by whom, based on what data? > > There are less than 10.000 LIRs in existance today, all RIRs combined. > According to my upper bound, it's already unnecessarily too large. So the *proof* mentioned above consists of "your personal feelings what the upper limit on the routing table size should be"? While I honour your feelings (I also think that the routing table shouldn't grow out of bounds), this is no "proof" that it's not going to scale. Also it brings back the problem of "who is worthy enough to receive one of 8192 TLAs", which was abandoned some 5 years ago, because there is no entity that can make this decision. > > 10.000 routing table entries is something far below the near 140.000 we > > have today in IPv4. While I'm seriously unhappy with the 140.000 IPv4 > > routes, it *does* scale up to fairly insane numbers. > > Of course, you can have as many routing table entries as you want, > as long as backbone routers, speed of which degrade as their routing > table bloat, have large enough routing table. Of course. But I tend to believe if people tell me "10k routes are no problem today". Oliver is building routers, with fast memory, and good routing table lookup algorithms. Today, high end routers can handle 140k routes. [..] > If the size of global routing table is limited by a hard upper > bound, it simplifies the design of routers a lot (you can put > a backbone router (or many of them) with a global routing table > in a chip), reduces cost of routers a lot and increases speed > of routers a lot. This is not going to work. *Inside* your AS, you will always have some more routes, and depending on the quality of your IGP aggregation, you might easily end up with more than 10k *internal* routes. So no matter what upper bound you put on the external routes, you cannot assume that nobody will ever need more routing table entries. Out of interest: what number do you suggest for the hard upper bound? > Note that, for scalable (thus, end to end) site multihoming properly > work, all the sites are required to circulate global routing table > within the sites. Actually, no. Not even in IPv4 today (which is part of the problem, that you can inject your prefix from a Cisco 2500 router, while everyone else needs to buy $costly hardware to *carry* your prefix). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-multi6@ops.ietf.org Tue Jun 29 04:29:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01438 for ; Tue, 29 Jun 2004 04:29:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfDyN-000My5-OU for multi6-data@psg.com; Tue, 29 Jun 2004 08:28:11 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BcqTd-000BuF-4u for multi6@ops.ietf.org; Tue, 22 Jun 2004 18:58:37 +0000 Received: (qmail 10679 invoked by uid 1007); 22 Jun 2004 18:58:36 -0000 Date: Tue, 22 Jun 2004 20:58:36 +0200 From: Gert Doering To: Kurt Erik Lindqvist Cc: Masataka Ohta , address-policy-wg@ripe.net, multi6@ops.ietf.org, Gert Doering , Sascha Luck Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") Message-ID: <20040622185835.GC6204@Space.Net> References: <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, On Tue, Jun 22, 2004 at 06:06:48PM +0200, Kurt Erik Lindqvist wrote: > On 2004-06-22, at 16.51, Masataka Ohta wrote: > > >> Ok, so you are actually proposing that we > > I'm actually proposing that you read the draft, if you > > are interested in multi6 issues. > For the record for the RIPE address policy WG, I will take this > discussion over to multi6 only. I would appreciate if you could send us an "executive summary", so that people over here that are not so well-versed in the different multi6 proposals can try to judge the benefits and costs of this proposal. Something that right now confuses *me* is: If I understand this correctly, the 'default-free zone' is meant to be kept below 1000 routes, so routers can be fast. But what about the internal structure of all these networks? At least the "internal core" boxes need to know all routes for the "NLI"s (or the NLIs' customers), which might well be many 1000s... thanks, Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-multi6@ops.ietf.org Tue Jun 29 04:39:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01960 for ; Tue, 29 Jun 2004 04:39:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfE7d-000O6Q-7L for multi6-data@psg.com; Tue, 29 Jun 2004 08:37:45 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfE7S-000O5Y-Hv for multi6@ops.ietf.org; Tue, 29 Jun 2004 08:37:34 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id C908A4846B4 for ; Tue, 29 Jun 2004 10:37:40 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <8FA9A741-C9A7-11D8-9D9B-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=US-ASCII; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Removed members Date: Tue, 29 Jun 2004 10:37:31 +0200 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The following list members will be removed due to bouncing or requests clerum@cutthroatcom.com mhayashi@idc.ad.jp ash@ash.de slblake@torrentnet.com dpb@yarbles.mojo.net lidefeng@huawei.com myipng@lycos.com akira@ttnet.ad.jp dkomata@ttnet.ad.jp doc@albert.tavian.com magnus@eriksson.mu julien@mail.sfc.wide.ad.jp - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQOEqUqarNKXTPFCVEQIx8wCeJYk7ZSycjWCqoLbQfrH7FdzDgAAAn3K2 txZoyThUy81IdczKdi2Pg9Vt =9zGQ -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jun 29 04:40:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02021 for ; Tue, 29 Jun 2004 04:40:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfE9f-000OKU-LU for multi6-data@psg.com; Tue, 29 Jun 2004 08:39:51 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1Bcry9-000MVt-BF for multi6@ops.ietf.org; Tue, 22 Jun 2004 20:34:13 +0000 Received: (qmail 15406 invoked by uid 1007); 22 Jun 2004 20:34:12 -0000 Date: Tue, 22 Jun 2004 22:34:12 +0200 From: Gert Doering To: Masataka Ohta Cc: Gert Doering , Kurt Erik Lindqvist , address-policy-wg@ripe.net, multi6@ops.ietf.org, Sascha Luck Subject: Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") Message-ID: <20040622203411.GG6204@Space.Net> References: <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> <40D888A1.7070901@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D888A1.7070901@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, On Wed, Jun 23, 2004 at 04:29:37AM +0900, Masataka Ohta wrote: > Note that routers in NLIs may have less performance than those > in TLIs. Why? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-multi6@ops.ietf.org Tue Jun 29 04:40:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02041 for ; Tue, 29 Jun 2004 04:40:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfEA7-000OOh-NH for multi6-data@psg.com; Tue, 29 Jun 2004 08:40:19 +0000 Received: from [158.38.62.77] (helo=smistad.uninett.no) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd8dz-000Ohr-8e for multi6@ops.ietf.org; Wed, 23 Jun 2004 14:22:31 +0000 Received: from localhost (localhost [127.0.0.1]) by smistad.uninett.no (Postfix) with ESMTP id 5A49420F32; Wed, 23 Jun 2004 16:22:29 +0200 (CEST) Date: Wed, 23 Jun 2004 16:22:29 +0200 (CEST) Message-Id: <20040623.162229.70984010.he@uninett.no> To: mohta@necom830.hpcl.titech.ac.jp Cc: gert@space.net, kurtis@kurtis.pp.se, address-policy-wg@ripe.net, multi6@ops.ietf.org, ripe-lst@eirconnect.net Subject: Re: [address-policy-wg] Re: Fallacy by Kurt From: Havard Eidnes In-Reply-To: <40D888A1.7070901@necom830.hpcl.titech.ac.jp> References: <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> <40D888A1.7070901@necom830.hpcl.titech.ac.jp> X-Mailer: Mew version 2.3 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > Something that right now confuses *me* is: If I understand this > > correctly, the 'default-free zone' is meant to be kept below 1000 > > routes, so routers can be fast. > > The hard limit is, IMO, 8192. Past history has told us that at least some technologists have failed miserably in predicting whether fast routers can be built which handle largish routing tables. If I recall correctly, an argument similar to the above one was one of the arguments the ATM proponents used in their day: you need a short header to do fast lookups, and "fast IP routers cannot be built". History since then has at least told me that this was not entirely accurate. Therefore, I tend to view the above justification and limits with a healthy dose of scepticism. Regards, - H=E5vard From owner-multi6@ops.ietf.org Tue Jun 29 07:33:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12458 for ; Tue, 29 Jun 2004 07:33:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfGpk-000J9t-8B for multi6-data@psg.com; Tue, 29 Jun 2004 11:31:28 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfGpX-000J8t-VC for multi6@ops.ietf.org; Tue, 29 Jun 2004 11:31:16 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5TBVEGm106926 for ; Tue, 29 Jun 2004 11:31:14 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5TBVEOa166428 for ; Tue, 29 Jun 2004 13:31:14 +0200 Received: from zurich.ibm.com (sig-9-145-225-140.de.ibm.com [9.145.225.140]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA86672 for ; Tue, 29 Jun 2004 13:31:13 +0200 Message-ID: <40E152D7.6070002@zurich.ibm.com> Date: Tue, 29 Jun 2004 13:30:31 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: identity persistence and comparison issues References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> In-Reply-To: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 28-jun-04, at 14:45, Erik Nordmark wrote: > >> And if the long-lived ID is one of the locators we can provide >> compatbility >> for unmodified applications which do referrals and callbacks. > > > We should really talk to some apps people to figure out how important > this is. It's entirely trivial to shoot yourself in the foot today with > NAT or multiple addresses anyway, and then there is dual stack. How are > referrals going to work when a future participant in the communication > may be limited to one IP version, which happens to be the other one than > the one used by current participants? > > It may very well be that apps and protocols need to be changed anyway in > order to work with IPv6, or IPv4+IPv6. The point is that today, the underlying assumption of most applications is that the IP address they get back from an A or AAAA query, or any other source including manual config, is a permanent identifier with the nice property that the routing system can use it as a locator. NAT breaks this assumption of course. But we are trying to repair the damage done by NAT. So I suggest that a multi6 goal should be that the thing an application gets back from an AAAA query, or any other source including manual config, must be a permanent identifier with the nice property that something below the socket API can transform it into a locator. Which leads me to wonder whether session survival for sessions using temporary things such as RFC 3041 addresses is a reasonable goal for multi6. Brian From owner-multi6@ops.ietf.org Tue Jun 29 07:42:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13026 for ; Tue, 29 Jun 2004 07:42:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfH08-000KWc-81 for multi6-data@psg.com; Tue, 29 Jun 2004 11:42:12 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfGzd-000KUA-9n for multi6@ops.ietf.org; Tue, 29 Jun 2004 11:41:42 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5TBfdGP065618; Tue, 29 Jun 2004 11:41:39 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5TBfckJ272316; Tue, 29 Jun 2004 13:41:38 +0200 Received: from zurich.ibm.com (sig-9-145-225-140.de.ibm.com [9.145.225.140]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA88578; Tue, 29 Jun 2004 13:41:38 +0200 Message-ID: <40E15569.9050005@zurich.ibm.com> Date: Tue, 29 Jun 2004 13:41:29 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 List CC: Kurt Erik Lindqvist Subject: Re: Next steps References: <2E5BF43F-BEEE-11D8-B677-000A95928574@kurtis.pp.se> In-Reply-To: <2E5BF43F-BEEE-11D8-B677-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There's only been one (positive) comment on this message so far. Now that the draft minutes are out, we would like to verify that there is indeed consensus on the list for this approach: - of course, finish our 4 chartered deliverable documents - focus on combining/consolidating the "Wedgelayer 3.5 / Fat IP" class of solution directions (noting that we are not actually chartered to write a solution specification); - continue individual work on items in the "Components" class, as potential building blocks. Support or objections within a week, please. Brian co-chair Kurt Erik Lindqvist wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > All, > > > During the interim Multi6 WG meeting in Santa Monica, the group > tried to come up with a classification of the proposals made so far > based on the classes used in Geoff Huston's > draft-huston-multi6-architectures-01.txt. During the interim meeting, > this classification was discussed and to some extent reordered. Below > you will find the outcome that we agreed on in the room: > > A. Addressing based > * draft-kurtis-multihoming-longprefix-00.txt > draft-savola-multi6-asn-pi-01.txt > draft-ohta-multihomed-isps-00.txt > draft-toyama-multi6-operational-site-multihoming-00.txt > draft-ohira-assign-select-e2e-multihome-01.txt > draft-van-beijnum-multi6-isp-int-aggr-01.txt > * draft-van-beijnum-multi6-2pi1a-00.txt > draft-ohira-multi6-multilink-auto-prefix-assign-00.txt > draft-teraoka-multi6-lin6-00.txt > > B. "Intermediate systems" > > * draft-bagnulo-multi6-mhexthdr-00.txt > draft-py-multi6-mhtp-01.txt > > C. Hostbased > draft-huitema-multi6-experiment-00.txt > draft-huitema-multi6-hosts-03.txt > > D. Tunnels > > E. Transport > draft-coene-sctp-multihome-04.txt > draft-coene-multi6-sctp-00.txt > draft-arifumi-multi6-tlc-fm-00.txt > draft-ohta-e2e-multihoming-05.txt > draft-ohta-multi6-8plus8-00.txt > > F. Wedgelayer 3.5 / Fat IP > draft-nordmark-multi6-cb64-00.txt > draft-nordmark-multi6-noid-01.txt > * draft-nordmark-multi6-sim-01.txt > draft-ylitalo-multi6-wimp-00.txt > draft-crocker-mast-proposal-01.txt > draft-nikander-multi6-hip-00.txt > draft-van-beijnum-multi6-odt-00.txt > > G. Components > draft-de-launois-multi6-naros-00.txt > draft-crocker-celp-00.txt > > > The drafts that are preceded with a "*" where withdrawn during the > interim meeting by their authors. The chairs now would like to proceed > with trying to limit the numer of classes of proposed solutions still > on the table and try and judge the support for each class. Based on > the discussions during the interim meeting it appears that there is no > or limited support for the solutions in class A, so we would like to > remove this class of solutions. The same goes for class B. As for > class C, we would like to move the hostbased approach into the > Components class (which we will explain below). As for the tunnels > class, the only proposal that we could come up with that would fit > would be Jerooen Massar's draft-massar-v6ops-ayiya-00.txt, which is > not a complete multihoming solution. We therefore propose to add this > to the components class. As for transport, we judge that although > there is some support for some of the solutions in the transport > class, it does seeem to be in the minority. This then leaves us with the > F class. The chairs would like to encourage the authors of drafts in > this category to work together to try and combine their ideas and if > possible come up with a common proposal. We _might_ appoint a > document editor for this class to help with the work and make sure we > make progress. > > As for the components class, this is a class of proposals that do > contain interesting ideas that might be worth studying further, but > that we believe do not constitute a full solution to the multihoming > problem in their own. > > The chairs hope that by using this approach, we would have few enough > proposals by the November IETF to start discussion on a final > proposal and singling out of a proposal to move further (i.e. > recharter). > > The chairs feel there was consensus in the room for this approach, > and would now like to find out if people on the list disagree. We > aim to produce a final agreed categorisation and list of next steps > within two weeks, so please send your comments now. > > Kurtis & Brian > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.3 > > iQA/AwUBQM8sU6arNKXTPFCVEQJZGwCeOWUyZQA0swRE0h5XkuUt9O2NlD8An1uT > q2LPtsVnkVvTLtmR78w3t0Xm > =PiIQ > -----END PGP SIGNATURE----- > > From owner-multi6@ops.ietf.org Tue Jun 29 07:48:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13336 for ; Tue, 29 Jun 2004 07:48:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfH5K-000LIc-E7 for multi6-data@psg.com; Tue, 29 Jun 2004 11:47:34 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfH56-000LGl-RE for multi6@ops.ietf.org; Tue, 29 Jun 2004 11:47:20 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5TBlGJ6026614; Tue, 29 Jun 2004 04:47:17 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5TBlB205966; Tue, 29 Jun 2004 13:47:12 +0200 (MEST) Date: Tue, 29 Jun 2004 01:43:33 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: cb64 To: marcelo bagnulo braun Cc: Erik Nordmark , Multi6 List In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > I have been re reading the cb64 draft, and i was wondering about the > fact that the IID is independent of the prefix. This was discarded in > SeND AFAIK in order to prevent dictionary attacks. Do you think that > cb64 should adopt a similar protection against these attacks? If we decide to pursue this approach further, this should definitely be looked at carefully. > In this case, the iid would differ among locators, and probably it > would be needed to change the id used. Perhaps the id could be the > public key rather than its hash (as in hip) ok. But this id would still be internal to the multihoming sublayer. > I don't know how much this change would affect the defined protocol. In > particular you would need to exchange the public key beforehand, which > is not currently required. this would add overhead when no additional > locator is needed, i am afraid. I don't see why one would need to pass the key earlier. One would have to change how the context is identified on reception from using the IID+flow label to only using the flow label (which limits each host to 1 million contexts; unless we carry an explicit larger contex tag in the packet as in SIM). But the protocol can still defer the public key operations until the first locator change as far as I can tell. Erik From owner-multi6@ops.ietf.org Tue Jun 29 07:51:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13638 for ; Tue, 29 Jun 2004 07:51:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfH7r-000Leb-6K for multi6-data@psg.com; Tue, 29 Jun 2004 11:50:11 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfH7d-000Lb7-UT for multi6@ops.ietf.org; Tue, 29 Jun 2004 11:49:58 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5TBntGP061798; Tue, 29 Jun 2004 11:49:55 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5TBnskJ283932; Tue, 29 Jun 2004 13:49:54 +0200 Received: from zurich.ibm.com (sig-9-145-225-140.de.ibm.com [9.145.225.140]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA50624; Tue, 29 Jun 2004 13:49:53 +0200 Message-ID: <40E1575A.9010709@zurich.ibm.com> Date: Tue, 29 Jun 2004 13:49:46 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Erik Nordmark CC: marcelo bagnulo braun , Jukka Ylitalo , Multi6 List Subject: Re: about Wedgelayer 3.5 / Fat IP approaches References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eik Nordmark wrote: >>what about cgas? >>They are locators, so you can use them for refferals to non multi6 apps >>and hosts, they allow to map from id to locators using reverse dns, and >>they are crypto in nature >>seems a good candidate to me :-) > > > A downside of CGA approaches is that they would, on a global basis, > cast the /64 subnet prefix boundary in stone forever. > This is different than SeND which only assumes the /64 on a single link, > and one can envision SeND evolving to handle different subnet prefix lengths > over time. > > Different people probably have very different level of concern for > "/64 forever in stone" ranging from it being a good simplification > to a fatal repeat of the 8 bit IPv4 network number + 24 bit host number > (before Class B and C was invented). Good point. The /64 boundary is only "architectural" in one place, stateless autoconfig, and even that is a changeable decision. CGAs have other downsides for multihoming, too. Brian From owner-multi6@ops.ietf.org Tue Jun 29 08:06:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14350 for ; Tue, 29 Jun 2004 08:06:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfHMJ-000Nls-6b for multi6-data@psg.com; Tue, 29 Jun 2004 12:05:07 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfHLw-000NiQ-IJ for multi6@ops.ietf.org; Tue, 29 Jun 2004 12:04:44 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i5TC2g53014588; Tue, 29 Jun 2004 06:02:43 -0600 (MDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5TC4R207710; Tue, 29 Jun 2004 14:04:28 +0200 (MEST) Date: Tue, 29 Jun 2004 05:04:24 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: identifiers and security To: Iljitsch van Beijnum , marcelo bagnulo braun Cc: Erik Nordmark , Multi6 In-Reply-To: "Your message with ID" <1599E638-C917-11D8-B450-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Sure, there always is an identifier, obviously I was getting at the > situation where there isn't new/separate value that fulfills this > function. BTW, I don't consider a _set_ of locators _a_ identifier, as > membership of the set presumably isn't fixed and having more than one > way to express the same identity (not the same thing as having more > than one identity) is a very bad idea. (X.400 anyone?) Fair enough. > > and whether those IDs are visible to the applications. > > Ah, but that's a very different issue. I think by definition the > identifiers are visible to the application. My choice of "visible" doesn't capture the distinction I wanted to make. Sorry. What I mean was whether the applications need to do something different because there is an ID (versus there just being a plain-old IPv6 address). The IDs can be visible, either by being part of an IPv6 locator, or by some new mechanism by which the application can ask the stack for the ID, but that wasn't the point I was trying to make. > > Taking NOID as an example of with no new ID namespace, the amount of > > work (in the form of DNS lookups in forward and reverse maps) > > will also result in stronger association between FQDNs and locators > > than we have today. > > Even if we assume DNSSEC? Assume DNSSEC for the baseline (current Internet), for NOID, or for both when comparing them? In the case of "both" it is still the case that NOID as currently specified performs extra checks; it would check the consistency between the reverse and forward DNS trees. This provides combined with the return routability checks implicit in establishing the context means that not only do the locators used have to be routable to the node, but the reverse DNS tree would also need to be delegated from the RIRs down to the person controlling the address space. DNSSEC only makes the delegations of the tree used be more secure; it does not mandate consistency checks between the forward tree, the reverse tree, and routing sending the packets to the node. > > I've certainly entertained ideas that are a lot weaker than NOID, > > for instance just have the peers exchange their sets of locators > > plus a cleartext cookie/context tag when the setup the state, > > and then do a RR check before sending packets to a new locator, > > but I've received pushback from folks that I wouldn't characterize as > > security geeks, that this would be too weak. > > I don't think this is universally true. Certainly, this is too weak for > TLS or IPsec sessions that can now be broken by an attacker, unlike > before. But why would this be too weak for talking to Google over > unprotected TCP/IP? If I recall correctly, the main concern is when attackers and nodes move around. In today's if an attacker is on the path it can cause damage to the communication if the communication isn't protected with something like IPsec or TLS. But this ability to cause damage is limited to the time period while the attacker is on the path. If we add some multihoming signaling whereby an attacker, which was on the path (e.g., by being on the same WiFi subnet as the victim) for a short time period, can cause damage by essentially using the state creation as a way to preserve it's on-path'ness forever, then folks are concerned. And since we want legitimate hosts/sites to have their communcation proceed after a failure of the locator they used when the communication was initiated, we can't require that a host is reachable at the original locator. This is why Marcelo correctly points out: > From a security POV, how different do you think that this solution > would be from a solution based in mipv6 with infinite BCE lifetimes? since it would have much the same security properties as mipv6 with infinite lifetimes. Thus for unsecured traffic the result would be weaker than today. The importance of this weakness can be debated - and we don't have much experience with attackers moving around so it is hard to have a firm basis for the debate. But what you brought to the table is that if we can ensure that secured traffic can not be redirected, by reusing the keys or otherwise "layering" on top of IPsec or TLS, then at least we would know that secured traffic could never be redirected by an attacker. So security-wise we'd gain some and loose some. > I suppose this wouldn't be much of a problem for IPsec. This could even > be done today by piping packets through a multihoming mechanism and > then take the resulting packets and feed them through IPsec. Obviously > this means more IPsec negotiation and state as now there must be an SA > for every locator pair used rather than one for the identifier pair. Yes. And with IKEv2 or MOBIKE this might be easier - I don't know. > I wouldn't want to try something like this with TLS, though. I'm > thinking more along the line of violating layers and modify IPsec/TLS > such that the wedge or modified IP can obtain keys that are exchanged > by modified IPsec/TLS. Something like putting the secret instructions > for the messager in the locked briefcase he's carrying. This works well > except for the first trip of course... This sounds tricky. I guess I don't know enough how the TLS keys (and which keys; is there some master key used to generate the RC4 key?, etc) can be exported from TLS. > > Thus something which is quite insecure (weaker than NOID as above) when > > IPsec isn't used, but when IPsec is used it is as strong as with IPsec > > in > > today's Internet. > > Is anybody interested in exploring these ideas further? > > Apart from me, you mean? (-: FWIW Doing the insecure signaling protocol for managing the contexts is something I can do; a version of such a spec can be created by taking the NOID spec and removing the places where it verifies things in the DNS. Saying it is layered above IPsec is also easy to say, but the difficulty is exploring the interaction with IPsec and IKE, as well as TLS. Erik From owner-multi6@ops.ietf.org Tue Jun 29 08:10:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14591 for ; Tue, 29 Jun 2004 08:10:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfHQ0-000OF1-Ql for multi6-data@psg.com; Tue, 29 Jun 2004 12:08:56 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfHPo-000OCe-So for multi6@ops.ietf.org; Tue, 29 Jun 2004 12:08:44 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5TC8aJ6003890; Tue, 29 Jun 2004 05:08:37 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5TC8V207911; Tue, 29 Jun 2004 14:08:32 +0200 (MEST) Date: Tue, 29 Jun 2004 05:08:30 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Engaging apps folks To: Iljitsch van Beijnum Cc: Erik Nordmark , Multi6 In-Reply-To: "Your message with ID" <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > On 28-jun-04, at 14:45, Erik Nordmark wrote: > > > And if the long-lived ID is one of the locators we can provide > > compatbility > > for unmodified applications which do referrals and callbacks. > > We should really talk to some apps people to figure out how important > this is. It's entirely trivial to shoot yourself in the foot today with > NAT or multiple addresses anyway, and then there is dual stack. How are > referrals going to work when a future participant in the communication > may be limited to one IP version, which happens to be the other one > than the one used by current participants? > > It may very well be that apps and protocols need to be changed anyway > in order to work with IPv6, or IPv4+IPv6. My experience, and I think Kurt said something similar, is that it is hard to engage application folks without something concrete like a proposal that they look at. This makes it tricky to get feedback before we have nailed down enough of the approach to be able write down how it will affect applications, unless we do the work to present the apps folks with a menu having different choices. Erik From owner-multi6@ops.ietf.org Tue Jun 29 08:28:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15574 for ; Tue, 29 Jun 2004 08:28:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfHhm-0000gA-4H for multi6-data@psg.com; Tue, 29 Jun 2004 12:27:18 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfHhY-0000ec-Ju for multi6@ops.ietf.org; Tue, 29 Jun 2004 12:27:04 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5TCQtil019879; Tue, 29 Jun 2004 06:26:56 -0600 (MDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5TCQk209040; Tue, 29 Jun 2004 14:26:47 +0200 (MEST) Date: Tue, 29 Jun 2004 05:26:45 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft remarks [multi6-threats] To: Iljitsch van Beijnum Cc: Erik Nordmark , Multi6 In-Reply-To: "Your message with ID" <6A8C89A5-C91E-11D8-B450-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > I don't have a problem adding a caveat about this in 1.1, but I'm > > trying > > to understand the cases that you are thinking off. > > Many networks and especially network elements such as switches today > have monitoring facilities. Those work only in one direction, so > inserting or blocking traffic can't be facilitated. Then there are > wireless networks that are often easy to eavesdrop on. Maybe... That aspect is already explicitly mentioned in section 1.1. In any case, I'll put in some "discussion" text in 1.1 as well. > > the attacker can also employ ARP/ND spoofing to get access to the > > packet flow which allows blocking as well. > > I suppose. But hopefully SEND will do something about that... SeND is good; doesn't mean it will be univerally deployed though. Hopefully there will be some deployment for public access IEEE networks at the edge, but I'm far from convinced enterprise networks will see the benefits. > IIRC, that is pretty much what it says now. My objection was that > people use ULP more in the sense "anything above the layer under > discussion", so your definition would be contrary to popular use. I guess I don't see the conflict. The layer under discussion is "IP". But there are only about 6 occurences of ULP in the draft and I think all of them are actually "transport layer" so I can easily get rid of the ULP term. Should I do that? > > I think preventing 3rd party flooding attacks doesn't have to be very > > complicated. But are you proposing that a node could send to a locator > > without having any assurance that the peer is in fact present at > > that locator i.e. without any form of RR check? > > No, that's not what I was saying. The trouble is that someone can > redirect. Periodically refreshing state means that an attacker must > impersonate the actual correspondent for a considerable amount of time > rather than just fire off something quickly. Obviously when a rehoming > event occurs this can no longer happen, so then we no longer allow new > locators to be added to the originally negotiated set. At some point > there is an RR check for all locators of course. OK. So one could allow new locators to be added as long as it is possible to check back with the original locator. That might be a useful technique. Was there something you wanted to see changed or added in section 3.4 in the draft about this, or was this a comment on the solution space? > > The more specific details in 4.3.1 and 4.3.2 seems to indicate to me > > that you actually need to verify that the peer is present at the > > claimed > > locator. > > Ok, then saying "I'm doing this because x.x.x.x asked me to" is > superfluous. I'm list. Can you send a suggested edit to the text in the document? > I'm still not convinced that the kernel wouldn't know this, but that's > not the issue as the MH layer knows at least something relevant: if > there is no state and we want to send data, we must create it so we are > initiating. Yes, we would be initiating the MH context setup. But if the state can be garbage collected, we might not have been initiating the application communication. > > Apart from the policy question, where different hosts might consider > > different > > things "secure" vs. "not secure", would it be possible to make any form > > of automatic detection of anything but the link attached to the host? > > One way would be a hop-by-hop option that routers pick up on and > modify. Another would be to simply filter a certain protocol and port > in insecure networks and assume that any link that doesn't allow those > packets through is less secure. That seems challenging deployment-wise, because by default all existing links would let everything through i.e. claim to be secure. I'm not sure that is what you want. Erik From owner-multi6@ops.ietf.org Tue Jun 29 09:02:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16893 for ; Tue, 29 Jun 2004 09:02:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfIEE-00047K-Hp for multi6-data@psg.com; Tue, 29 Jun 2004 13:00:50 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfIDy-00045h-Ee for multi6@ops.ietf.org; Tue, 29 Jun 2004 13:00:34 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5TD0Wil005274; Tue, 29 Jun 2004 07:00:33 -0600 (MDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5TD0S212339; Tue, 29 Jun 2004 15:00:29 +0200 (MEST) Date: Tue, 29 Jun 2004 06:00:27 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: identity persistence and comparison issues To: Brian E Carpenter Cc: Multi6 In-Reply-To: "Your message with ID" <40E152D7.6070002@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > NAT breaks this assumption of course. But we are trying to repair the > damage done by NAT. So I suggest that a multi6 goal should be that the > thing an application gets back from an AAAA query, or any other source > including manual config, must be a permanent identifier with the > nice property that something below the socket API can transform it > into a locator. Agreed, except that temporary/permanent is not binary but a continutiy of different lifetimes. > Which leads me to wonder whether session survival for sessions using > temporary things such as RFC 3041 addresses is a reasonable goal for > multi6. rfc 3041 temporary addresses have a default valid lifetime of 1 week. So why wouldn't be reasonable for connections using such addresses to be able to survive failures that last for a few minutes or hours? Having said that, solutions which rely on the DNS for verifications might be tricky unless the RFC 3041 addresses have forward and reverse DNS entires (with a temporary FQDN to prevent correlation to the other IP addresses of the host). But this difficulty should distract from the desirability of making things work for RFC 3041 addresses IMHO. Erik From owner-multi6@ops.ietf.org Tue Jun 29 09:08:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17381 for ; Tue, 29 Jun 2004 09:08:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfIKm-00054Q-Vu for multi6-data@psg.com; Tue, 29 Jun 2004 13:07:36 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfIKW-00051W-AQ for multi6@ops.ietf.org; Tue, 29 Jun 2004 13:07:20 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5TD7EFA079444; Tue, 29 Jun 2004 13:07:14 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5TD7DOa152888; Tue, 29 Jun 2004 15:07:13 +0200 Received: from zurich.ibm.com (sig-9-145-225-140.de.ibm.com [9.145.225.140]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA58818; Tue, 29 Jun 2004 15:07:12 +0200 Message-ID: <40E16979.4050502@zurich.ibm.com> Date: Tue, 29 Jun 2004 15:07:05 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Erik Nordmark CC: Iljitsch van Beijnum , Multi6 Subject: Re: Engaging apps folks References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>On 28-jun-04, at 14:45, Erik Nordmark wrote: >> >> >>>And if the long-lived ID is one of the locators we can provide >>>compatbility >>>for unmodified applications which do referrals and callbacks. >> >>We should really talk to some apps people to figure out how important >>this is. It's entirely trivial to shoot yourself in the foot today with >>NAT or multiple addresses anyway, and then there is dual stack. How are >>referrals going to work when a future participant in the communication >>may be limited to one IP version, which happens to be the other one >>than the one used by current participants? >> >>It may very well be that apps and protocols need to be changed anyway >>in order to work with IPv6, or IPv4+IPv6. > > > My experience, and I think Kurt said something similar, is that it > is hard to engage application folks without something concrete like > a proposal that they look at. This makes it tricky to get feedback before > we have nailed down enough of the approach to be able write down how it > will affect applications, unless we do the work to present the apps folks > with a menu having different choices. What they see is an API and its explicit and implied semantics. So not only do we need to resolve the endless debate about the nature of an id, we also have to figure out how that will be represented in socket semantics. From painful experience, it is not easy to persuade middleware designers to change anything in the way they use sockets. Brian From owner-multi6@ops.ietf.org Tue Jun 29 10:08:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20121 for ; Tue, 29 Jun 2004 10:08:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfJFN-000BRI-T2 for multi6-data@psg.com; Tue, 29 Jun 2004 14:06:05 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfJEw-000BNY-Qn for multi6@ops.ietf.org; Tue, 29 Jun 2004 14:05:39 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id A8E368582; Tue, 29 Jun 2004 16:05:35 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 09776-35; Tue, 29 Jun 2004 16:05:12 +0200 (CEST) Received: from [9.4.70.109] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id CCE557F67; Tue, 29 Jun 2004 16:05:11 +0200 (CEST) Subject: Re: Engaging apps folks From: Jeroen Massar To: Brian E Carpenter Cc: Erik Nordmark , Iljitsch van Beijnum , Multi6 In-Reply-To: <40E16979.4050502@zurich.ibm.com> References: <40E16979.4050502@zurich.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ngLieTEu4nIWFfGkc4Vj" Organization: Unfix Message-Id: <1088517904.20311.175.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 29 Jun 2004 16:05:05 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk --=-ngLieTEu4nIWFfGkc4Vj Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-06-29 at 15:07, Brian E Carpenter wrote: > Erik Nordmark wrote: > >>On 28-jun-04, at 14:45, Erik Nordmark wrote: > >> > >> > >>>And if the long-lived ID is one of the locators we can provide=20 > >>>compatbility > >>>for unmodified applications which do referrals and callbacks. > >> > >>We should really talk to some apps people to figure out how important=20 > >>this is. It's entirely trivial to shoot yourself in the foot today with= =20 > >>NAT or multiple addresses anyway, and then there is dual stack. How are= =20 > >>referrals going to work when a future participant in the communication=20 > >>may be limited to one IP version, which happens to be the other one=20 > >>than the one used by current participants? > >> > >>It may very well be that apps and protocols need to be changed anyway=20 > >>in order to work with IPv6, or IPv4+IPv6. getaddrinfo() doesn't require much changes on the network code front. The user interface though tends to break when it forces a certain format or restricts input. Developers should stick to accepting at least hostname or actually any characters in [a-zA-Z\:\-\.], the problem here is though that for IPv6 suddenly if you want to parse a URI and allow IPv6 addresses to be specified you need to know about the [] semantics. The trick IMHO is to never allow IP addresses to be used basically. But there are many arguments against this eg 'how do I setup my home-gateway which comes pre-installed as 2001:db8::1, that thing is going to run DNS and I need to connect using HTTP'. Simple solution: /etc/hosts but still ;) > > My experience, and I think Kurt said something similar, is that it > > is hard to engage application folks without something concrete like > > a proposal that they look at. This makes it tricky to get feedback befo= re > > we have nailed down enough of the approach to be able write down how it > > will affect applications, unless we do the work to present the apps fol= ks > > with a menu having different choices. >=20 > What they see is an API and its explicit and implied semantics. So not on= ly > do we need to resolve the endless debate about the nature of an id, we al= so > have to figure out how that will be represented in socket semantics. >=20 > From painful experience, it is not easy to persuade middleware designers > to change anything in the way they use sockets. Even pursuading folks to start using getaddrinfo() doesn't work that easily and most of them have a point. A network application developer actually only wants this: 8<--------- char uri[] =3D "tcp://hostname:service"; sock =3D uriconnect(uri); -------->8 A function similar like that should be abstracted by the networking API's. getaddrinfo() requires a loop, weird cases etc, which you have to duplicate in every application. The above would simply work(tm) and doesn't require the application developer to worry about anything networkish. The socket now presented by the API is for the application the identifier and the only thing the API (or most probably the kernel) would now have to do is make bloody sure that it keeps working, even if it has to change underlying addresses etc. uriconnect() can abstract all of that, the socket(), getaddrinfo() loop and the connect() call. The identifier 'tcp://hostname:service' in this case will stay the same and can be passed across most if not any boundaries (of course not taking the assumption that somebody uses dns paths...) to other applications in other networks etc. Another option to look at is adding a function getidentifier(sock)*, which returns a globally unique (we did have an globally unique IP address hmmm... :) identifier, which then can be passed around. The later is IMHO not a nice option as that would require changing many applications (for IPv6 support they will have to change too so it is kind of a moot argument), though it could be used. The getidentifier() could btw return 'tcp://fdqn:service' making sure the above problem with dns-path searches disappears. I could then still do: sock =3D uriconnect("tcp://purgatory:http"); to contact the http service on purgatory.unfix.org, as my search path includes 'unfix.org', while when I want to pass it, I would do: fprintf(sock, "I am looking at: %s", getidentifier(sock)); or a similar construction, which would throw: "I am looking at: tcp://purgatory.unfix.org:http" Server side can do the same: sock =3D uriaccept("tcp://:http"); printf("The one who connected is %s\n", getidentity(sock));=20 Thus passing URL-like identities in applications seem to be the trick IMHO, an application developer should not have to care about anything else. Of course the other side app should then also know about HTTP etc Long story short: Maybe it would be an idea to create a draft which includes the examples I mentioned above and start hinting developers to start using those functions? Greets, Jeroen * =3D of course: char *getidentifier(int socket, char *buffer, unsigned int buflen); to make sure that it also works with multithreaded apps... PS: Including the protocol (tcp/udp) won't work easily for server side stuff... especially with udp not really having an accept. PS2: I usually tend to abstract the socket/getaddrinfo/connect into a function like the one mentioned above and that works perfectly well. PS3: 'High-performance' networking API's like those on Windows have a completely different strategy of doing things thus fitting those into the above model will be problematic too... --=-ngLieTEu4nIWFfGkc4Vj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBA4XcQKaooUjM+fCMRAgFqAKCcFITAChUw5tRXC5rrEQmY734ufQCfSky5 DkGNDKnhGd4iiPnryHfuEKw= =iJ/R -----END PGP SIGNATURE----- --=-ngLieTEu4nIWFfGkc4Vj-- From owner-multi6@ops.ietf.org Tue Jun 29 10:10:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20460 for ; Tue, 29 Jun 2004 10:10:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfJJ3-000C4D-Ol for multi6-data@psg.com; Tue, 29 Jun 2004 14:09:53 +0000 Received: from [128.182.66.106] (helo=mailer2.psc.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfJIl-000C1A-Gj for multi6@ops.ietf.org; Tue, 29 Jun 2004 14:09:35 +0000 Received: from [128.182.61.59] (lassa.psc.edu [128.182.61.59]) (authenticated bits=0) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id i5TE9XAf019074 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 29 Jun 2004 10:09:34 -0400 (EDT) Message-ID: <40E1781F.4060508@psc.edu> Date: Tue, 29 Jun 2004 10:09:35 -0400 From: Michael Lambert Reply-To: Multi6 List User-Agent: Mozilla Thunderbird 0.6 (Macintosh/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Multi6 List Subject: Re: Next steps References: <2E5BF43F-BEEE-11D8-B677-000A95928574@kurtis.pp.se> <40E15569.9050005@zurich.ibm.com> In-Reply-To: <40E15569.9050005@zurich.ibm.com> X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The following all appear to be expired drafts (at least they are not current in the IETF ID repository): > draft-ohta-multihomed-isps-00.txt > draft-ohira-assign-select-e2e-multihome-01.txt (and -02 as well) > draft-van-beijnum-multi6-isp-int-aggr-01.txt > draft-py-multi6-mhtp-01.txt > draft-huitema-multi6-experiment-00.txt > draft-ohta-e2e-multihoming-05.txt > draft-nordmark-multi6-cb64-00.txt > draft-nordmark-multi6-noid-01.txt > draft-crocker-mast-proposal-01.txt > draft-de-launois-multi6-naros-00.txt Do the authors have plans to revise and resubmit? Michael From owner-multi6@ops.ietf.org Tue Jun 29 10:29:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22297 for ; Tue, 29 Jun 2004 10:29:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfJaB-000DyM-46 for multi6-data@psg.com; Tue, 29 Jun 2004 14:27:35 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfJZs-000Dwe-S4 for multi6@ops.ietf.org; Tue, 29 Jun 2004 14:27:17 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DC75F270B8; Tue, 29 Jun 2004 16:27:15 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp02.uc3m.es (Postfix) with ESMTP id C5E9427042; Tue, 29 Jun 2004 16:27:15 +0200 (CEST) In-Reply-To: <40E1575A.9010709@zurich.ibm.com> References: <40E1575A.9010709@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8E1939A4-C9D8-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Jukka Ylitalo , Multi6 List , Erik Nordmark From: marcelo bagnulo braun Subject: Re: about Wedgelayer 3.5 / Fat IP approaches Date: Tue, 29 Jun 2004 16:28:14 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 29/06/2004, a las 13:49, Brian E Carpenter escribi=F3: > Eik Nordmark wrote: >>> what about cgas? >>> They are locators, so you can use them for refferals to non multi6=20= >>> apps and hosts, they allow to map from id to locators using reverse=20= >>> dns, and they are crypto in nature >>> seems a good candidate to me :-) >> A downside of CGA approaches is that they would, on a global basis, >> cast the /64 subnet prefix boundary in stone forever. >> This is different than SeND which only assumes the /64 on a single=20 >> link, >> and one can envision SeND evolving to handle different subnet prefix=20= >> lengths >> over time. >> Different people probably have very different level of concern for >> "/64 forever in stone" ranging from it being a good simplification >> to a fatal repeat of the 8 bit IPv4 network number + 24 bit host=20 >> number >> (before Class B and C was invented). > > Good point. The /64 boundary is only "architectural" in one place,=20 > stateless > autoconfig, and even that is a changeable decision. > > CGAs have other downsides for multihoming, too. > such as? regards, marcelo > Brian > From owner-multi6@ops.ietf.org Tue Jun 29 10:37:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23074 for ; Tue, 29 Jun 2004 10:37:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfJjK-000FHi-Ks for multi6-data@psg.com; Tue, 29 Jun 2004 14:37:02 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfJh6-000Evq-SF for multi6@ops.ietf.org; Tue, 29 Jun 2004 14:34:45 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1935C272D9; Tue, 29 Jun 2004 16:34:44 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp02.uc3m.es (Postfix) with ESMTP id 052D827340; Tue, 29 Jun 2004 16:34:44 +0200 (CEST) In-Reply-To: <40E152D7.6070002@zurich.ibm.com> References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <98F51062-C9D9-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Multi6 From: marcelo bagnulo braun Subject: Re: identity persistence and comparison issues Date: Tue, 29 Jun 2004 16:35:41 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 29/06/2004, a las 13:30, Brian E Carpenter escribi=F3: > Iljitsch van Beijnum wrote: >> On 28-jun-04, at 14:45, Erik Nordmark wrote: >>> And if the long-lived ID is one of the locators we can provide=20 >>> compatbility >>> for unmodified applications which do referrals and callbacks. >> We should really talk to some apps people to figure out how important=20= >> this is. It's entirely trivial to shoot yourself in the foot today=20 >> with NAT or multiple addresses anyway, and then there is dual stack.=20= >> How are referrals going to work when a future participant in the=20 >> communication may be limited to one IP version, which happens to be=20= >> the other one than the one used by current participants? >> It may very well be that apps and protocols need to be changed anyway=20= >> in order to work with IPv6, or IPv4+IPv6. > > The point is that today, the underlying assumption of most = applications > is that the IP address they get back from an A or AAAA query, or any > other source including manual config, is a permanent identifier with > the nice property that the routing system can use it as a locator. > > NAT breaks this assumption of course. But we are trying to repair the > damage done by NAT. So I suggest that a multi6 goal should be that the > thing an application gets back from an AAAA query, or any other source > including manual config, including a referral? > must be a permanent identifier with the > nice property that something below the socket API can transform it > into a locator. > i agree with this regards, marcelo > Which leads me to wonder whether session survival for sessions using > temporary things such as RFC 3041 addresses is a reasonable goal for > multi6. > > Brian > From owner-multi6@ops.ietf.org Tue Jun 29 11:20:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26246 for ; Tue, 29 Jun 2004 11:20:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfKNx-000KGO-D1 for multi6-data@psg.com; Tue, 29 Jun 2004 15:19:01 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfKNe-000KF7-16 for multi6@ops.ietf.org; Tue, 29 Jun 2004 15:18:42 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 295012740B; Tue, 29 Jun 2004 17:18:41 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp02.uc3m.es (Postfix) with ESMTP id 10EA0273E0; Tue, 29 Jun 2004 17:18:41 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: marcelo bagnulo braun Subject: Re: draft-nordmark-multi6-threats-01.txt Date: Tue, 29 Jun 2004 17:19:38 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> For instance, you can think a solution where each connection is >> handled >> independently, and has its own security, So attackers have to redirect >> each connection independently, no matter the direction the connection >> is established. Examples of this are solutions that make TCP to >> support >> multiple addresses per connection. > Disclaimer: i am not advocating for this type of solution, i am just considering the different levels of threats introduced by one or other approach > Yes, but it is hard to see how such an approach would apply to UDP. UDP is not connection oriented, so this per connection type of solution needs to be implemented at a level who is connection aware. imho in the UDP case, you will need to implement it at the app layer > And I think applying such a TCP solution to http traffic would be > insane > due to the performance impact of doing more work for every short > connection. > Even so, since there are long-lived http connections, I think it would > be bad to remove the ability for them to benefit from multihoming. > So you'd definitely need a MAST type approach here were the signalling > can be deferred until you can guess that the connection will be long > lived > enough to benefit from the multihoming state being established. i agree with all your points. However, as is stated above, my point here is just about the differences in security/threats between per connection security and per direction security and per endpoint security > >> Next, you have solutions that explicitly handle different directions >> of >> communication separately. This means that all incoming communications >> from a given endpoint share the same set of locators, and an attack >> will affect established and future incoming communication evenly. the >> same for outgoing communications. I guess that an example of this >> would >> be wimp. This makes sense, imho because as you mention in the draft, >> the initiator role and the responder role are different in terms of >> identity requirement. In many cases the identity of the initiator is >> not very important, the only relevant issue is that it remains the >> same >> that had initiated the communication. OTOH, the receiver identity is >> always important since the initiator wants to communicate with a >> certain host. > > Hmm - perhaps "incoming" and "outgoing" is being overloaded when we > take > WIMP into account. I view WIMPs use of ephemeral IDs as a separate step > of creating an identity on the fly which is conceptually separate > from that node initiating communication by sending a UDP packet > or a TCP SYN. > WIMP uses different type of id for initiators and for receivers: - for initiators, the id is randomly created - for receivers, the id=hash(FQDN) Note that a single endpoint can be both intitator and receiver, so it will have multiple ids of different types So, imho identities in wimp are closely related to who has initiated the communication i.e. initiator and receiver > >> Finally, some solutions handle all the communications together, >> incoming and outgoing. Such solutions (like noid, sim) require heavier >> security features in all communications, since no matter whether the >> communication requires identity validation or not, this feature is >> provided >> >> That is why i see that the issue to be about the scope of the binding >> information. >> We need some security mechanisms to negotiate the binding between a >> set >> of locators and the identifier used by ULP >> The point is the scope of this binding. >> This binding can affect only a a given communication >> this binding can affect all the incoming (or outgoing) communications >> this binding can affect all the communications with a given endpoint. >> >> As the binding affects more communications, the security required for >> the mechanism to set up the binding would be stronger, imho > > You seem to be basing this on the assumption that each communication > provides > a fixed security quantum and it is the sum of these quanta over all all > communication that matters. that was not my intention. i am assuming that it is worse that an attacker hijacks all the present and future communications than just hijacking a single connection. So, a single communication requires less security than all the present and future communications in one direction which in turns requires less security that all present and future communication communications in both directions. I mean, if a single communication is at stake the solution needs less security than when all the communications are at stake. > > That doesn't make sense to me, since I don't think things are that > uniform. > For example, the communication which a sensor initiates to report a > fire has > higher security requirements (for instance, needs higher DoS > resistance) > than periodic temperature readings from the same sensor (that might be > used > to fine tune the air conditioning settings). > > I care a lot more about the security when accessing my bank than when > accessing a news site. > Thus not all communication have the same security requirements. > Hence assuming a fixed security "contribution" per communication > doesn't make sense to me. > I guess that different apps will have different security requirements. However, i am considering the default scenario here. I mean the multi6 solution will provide some default level of security based on some security tools used by the solution. If a particular communication requires additional security, it will obtain it by special means (TLS for instance) >> i think this is a good point. >> When considering per connection solutions, the time is naturally >> limited to the lifetime of the connection. The problem is when you >> attempt to use the binding information for more than a single >> connection (or when the mechanism resides in a layer that has no >> knowledge of the connections) In this case, you need a garbage >> collection mechanisms, to delete the bindings that are no longer being >> used. As you mention, the presence of this information when it is no >> longer needed for the communication is a liability, and would make >> sense to delete asap > > I don't think I said it was a liability; when applications perform > repetitive connections over a short time period there is a great > benefit in being able to retain the multihoming state > across those connections. Likewise if multiple parallel > connections seem to be useful to some applications. > > My take is why per-connection TCP solutions are simpler than a common, > connection indepdent solution, is two-fold: > - the identifier space is effectively different. TCP cares about the > 5-tuple > indentifying the connection and as a result, connection redirection, > but it doesn't need to care whether multiple peers are claiming to > use the same 128-bit identifier as long as the connections are > uniquely > identified by the 5-tuple. and stealing a connection does not imply stealing other (future and present) connections > - state setup and taredown can be bound to the open and close > handshakes of > the protocol. > > The first point is interesting to compare to ephemeral IDs. For many > TCP > applications the initiator's port number floats that is the 5-tuple > connection identifier will be ephemeral as a result; even if the > variation > is less than 16 bits. indeed. however, because multi6 layer located mechanisms are not connection aware, they cannot limit the scope of the id to a single connection > This means that one can perhaps be less concerned about premeditated > redirection? yes. imho, we can be less concerned about redirection in general, becuase redirection attack will only affect a single connection, and the ephemeral nature of the id imples that future communication may use a different id > > >>> Yes, for the responding end. >>> The interesting thing I tried to bring out is that for the >>> end that has the ephemeral ID, you can skirt around the premediated >>> attacks (assuming the solution has a robust way to pick a new ID when >>> one is in use/stolen). >> >> Yes and the cool thing is that the node that has an ephemeral id does >> no need a stable one when he is acting as an initiator, so providing >> it >> to him would require additional security without any benefits (which >> doesn't seems a reasonable tradeoff :-) > > Yes, if you somehow know that the application will not try to use that > ID on a longer timescale whether for identity comparison, callbacks or > referrals. > >> But imho in the case of ephemeral ids, you are not really proving id >> ownership, because the identity is meaningless! > > It is meaningless on a longer timescale and for the applications, but > it might > be critical to be able to redirect existing communication to use a > different > locator. Thus you can view this as a first-come first-serve ID claim > protocol > with any given peer; once a node has claimed an ID at the peer it > can use that ID to affect the locators that are used to reach it. yes, this is more accurate regards, marcelo > >> So you don't really have to prove id ownership because it is >> irrelevant >> The important point in this scenario is that the the communication is >> always with the same endpoint. > > Exactly, which I why I say there is an ID in this case. > > > >> Ok, i agree that i should be more precise about this point. >> Perhaps the important issue in this case is that a given endpoint is >> authorized to use a given locator (i think G. Montenegro used this >> expression about locators a while ago) >> >> So we need to provide identity ownership proofs and locator usage >> authorization proofs in order to make this work >> >> So, assuming the above taxonomy of means to provide identity ownership >> proof, the mechanisms to provide locator usage authorization proof >> would be: >> >> - return routability: i.e. if an endpoint is capable of receiving >> packets at a given locator, it is because he is authorized to do so >> - third trusted party: a third party establishes that a given identity >> is authorized to use a given set of locators (for instance the DNS) > > Yes. I'll try to add this into the appendix. > > Erik > > From owner-multi6@ops.ietf.org Tue Jun 29 12:17:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29347 for ; Tue, 29 Jun 2004 12:17:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfLGr-000108-RZ for multi6-data@psg.com; Tue, 29 Jun 2004 16:15:45 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfLGa-0000yg-4q for multi6@ops.ietf.org; Tue, 29 Jun 2004 16:15:28 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Tue, 29 Jun 2004 09:15:26 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 29 Jun 2004 09:14:15 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 29 Jun 2004 09:14:16 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 29 Jun 2004 09:14:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: identity persistence and comparison issues Date: Tue, 29 Jun 2004 09:14:14 -0700 Message-ID: Thread-Topic: identity persistence and comparison issues thread-index: AcRdzXT5vll49ZYzQCOvJWBKNokaMgAJRPgg From: "Christian Huitema" To: "Brian E Carpenter" , "Multi6" X-OriginalArrivalTime: 29 Jun 2004 16:14:12.0948 (UTC) FILETIME=[1DF90940:01C45DF4] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > The point is that today, the underlying assumption of most applications > is that the IP address they get back from an A or AAAA query, or any > other source including manual config, is a permanent identifier with > the nice property that the routing system can use it as a locator. Is that actually true? Looking at my own neighborhood, I see the following: 1) The most popular applications, web browsing and e-mail, do not make the assumption that addresses are identifiers. Web servers commonly use techniques such as DNS load balancers, and the clients see a different address every time. Mail clients typically resolve a domain name before any attempt to communicate with a server. 2) The vast majority of networking applications are not written to the socket API. They are typically written in Visual Basic, C# or other high level languages, and they interface the network through high level calls such as RPC, DCOM or WinInet (an API to the HTTP protocol). The underlying libraries do not assume that the addresses are fixed; the API typically uses a service name or a server name, not an IP address. 3) Emerging applications written around instant messaging services, peer to peer services or SIP do not assume that a host address is fixed. Indeed, the SIP payloads carry the "current IP address" at which a SIP UA expects to receive packets.=20 Indeed, most of these applications have a concept of "session", and expect that the addresses will remain stable for the duration of the session. But many also have a capability to reconnect if the session is interrupted, and the reconnection procedures typically include a name resolution. -- Christian Huitema From owner-multi6@ops.ietf.org Tue Jun 29 16:49:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19107 for ; Tue, 29 Jun 2004 16:49:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfPW8-000FCx-PI for multi6-data@psg.com; Tue, 29 Jun 2004 20:47:48 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfPW4-000FBa-Gv for multi6@ops.ietf.org; Tue, 29 Jun 2004 20:47:44 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5TKn82r008151 for ; Tue, 29 Jun 2004 22:49:10 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <906B9382-CA0D-11D8-9359-000A95CD987A@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Multi6 From: Iljitsch van Beijnum Subject: Install DNS mappings based on TLS/IPsec? Date: Tue, 29 Jun 2004 22:47:41 +0200 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit One of the problems we may have to solve is a mapping system from an identifier to a set of locators, or from a single locator to the full set. A straightforward way to do this would be routable IP address -> FQDN -> full set of routable IP addresses. Unfortunately, this requires that both the forward and reverse DNS trees are populated properly. This in itself is somewhat hard (but doable for well-managed sites, if not for ad-hoc and "basement multihoming" situations). However, without full deployment of DNSSEC this information isn't particularly trustworthy. It occurs to me that there may be an alternative way to make these FQDN <-> address mappings available: they can be negotiated as part of the IPsec or TLS negotiations. Think about it: TLS already verifies ownership of a FQDN, so after that any FQDN -> address mappings that are provided are supposedly trustworthy, and more so than information learned through unprotected DNS queries. In many cases, a reverse lookup (address -> FQDN) isn't necessary, but if it is, things get more complicated. It's not inconceivable that someone would want to override valid reverse mapping information in the DNS with invalid information negotiatated with IPsec/TLS. For instance, I may have a valid certificate for justforkicks.net and I could tell you that the addresses that belong to Google actually map to justforkicks.net and then any time Google spiders your website my domain name shows up in your logs. Not immediately fatal, but problematic nonetheless. This problem can be solved in one of two ways: 1. only allow installing reverse mapping if there aren't any present in the DNS 2. only allow installing reverse mapping for addresses that wouldn't normally be used for non-MH purposes An example of the addresses under 2. could be RFC 3041 addresses. Those can be used for non-MH purposes, but presumably not for anything that would be bothered by injecting false reverse DNS information. I.e. as long as people don't use RFC 3041 addresses for anything worth MH protection there is no problem. Another choice would be addresses derived from EUI-64s with the u/l flag set to global and the group bit set. There is currently no reasonable way that such addresses show up by accidentt. I think that such a mechanism would very nicely compliment a NOID-like solution, as it effectively removes dependency on the DNS for a large number of applications. At the same time, the solution in question can be deployed without having to wait for this mechanism to be implemented; it can be put to use as soon as it's available, in the mean time there's the DNS. From owner-multi6@ops.ietf.org Tue Jun 29 20:52:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11804 for ; Tue, 29 Jun 2004 20:52:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfTJ1-0002ma-7p for multi6-data@psg.com; Wed, 30 Jun 2004 00:50:31 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfTIz-0002lb-Ln for multi6@ops.ietf.org; Wed, 30 Jun 2004 00:50:29 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id RAA05543; Tue, 29 Jun 2004 17:50:14 -0700 (PDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i5U0oDP22969; Tue, 29 Jun 2004 19:50:13 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Tue, 29 Jun 2004 17:49:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: about Wedgelayer 3.5 / Fat IP approaches Date: Tue, 29 Jun 2004 17:49:51 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060720@xch-nw-27.nw.nos.boeing.com> Thread-Topic: about Wedgelayer 3.5 / Fat IP approaches Thread-Index: AcRc6FyXlqj6knTbT7unNMQYXdCV9QBTe4jw From: "Henderson, Thomas R" To: "Jukka Ylitalo" , "Erik Nordmark" Cc: "marcelo bagnulo braun" , "Multi6 List" X-OriginalArrivalTime: 30 Jun 2004 00:49:52.0608 (UTC) FILETIME=[27727E00:01C45E3C] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Jukka Ylitalo [mailto:jukka.ylitalo@nomadiclab.com]=20 > Sent: Monday, June 28, 2004 1:09 AM > To: Erik Nordmark > Cc: marcelo bagnulo braun; Multi6 List > Subject: Re: about Wedgelayer 3.5 / Fat IP approaches >=20 > It would be also possible to change HIP in a way that the applications > were to see routable IP-addresses, instead of HITs. =20 > Basically, the Multi6 > enhanced HIP would implement a NOID kind of AID-locator=20 > split. In this way, > it would be possible to use HIP in an opportunistic mode, like SSH. > I believ that the application layer will be the key element when=20 > combining different > wedge3.5 proposals. Rather than NOID kind of split, maybe CB64-like split is preferable? (where lower bits of AID match the HIT and upper bits the prefix, rather than having the AID be unrelated to the HIT)? It wouldn't have to be a /64 split necessarily-- just reverse mappable with DNSSEC. I agree that HIP opportunistic mode should be able to=20 deal with it. Already in HIP there has been some struggle with what AID to pass to applications, and some level of discomfort with passing non routable values posing as IP addresses to legacy apps, for many of=20 the reasons cited in the previous posts (see also Appendix A of the draft HIP base spec). For legacy APIs and legacy apps, then,=20 maybe this kind of AID/m6 identifier split could satisfy the referral issue, or perhaps instead being underpinned by WIMP or other lighter-weight m6 identifier, as you and Erik suggest. Tom From owner-multi6@ops.ietf.org Tue Jun 29 21:13:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12710 for ; Tue, 29 Jun 2004 21:13:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfTfC-0005jj-5h for multi6-data@psg.com; Wed, 30 Jun 2004 01:13:26 +0000 Received: from [207.69.200.110] (helo=smtp6.mindspring.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfTfB-0005jW-6H for multi6@ops.ietf.org; Wed, 30 Jun 2004 01:13:25 +0000 Received: from 1cust103.tnt36.dfw9.da.uu.net ([67.234.81.103] helo=ix.netcom.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 1BfTf2-0006gz-00; Tue, 29 Jun 2004 21:13:17 -0400 Message-ID: <40E22D1B.8B52A674@ix.netcom.com> Date: Tue, 29 Jun 2004 20:01:51 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 Subject: Re: identity persistence and comparison issues References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_NJABL, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian and all, Brian E Carpenter wrote: > Iljitsch van Beijnum wrote: > > On 28-jun-04, at 14:45, Erik Nordmark wrote: > > > >> And if the long-lived ID is one of the locators we can provide > >> compatbility > >> for unmodified applications which do referrals and callbacks. > > > > > > We should really talk to some apps people to figure out how important > > this is. It's entirely trivial to shoot yourself in the foot today with > > NAT or multiple addresses anyway, and then there is dual stack. How are > > referrals going to work when a future participant in the communication > > may be limited to one IP version, which happens to be the other one than > > the one used by current participants? > > > > It may very well be that apps and protocols need to be changed anyway in > > order to work with IPv6, or IPv4+IPv6. > > The point is that today, the underlying assumption of most applications > is that the IP address they get back from an A or AAAA query, or any > other source including manual config, is a permanent identifier with > the nice property that the routing system can use it as a locator. > > NAT breaks this assumption of course. But we are trying to repair the > damage done by NAT. NAT has nor is doing any damage. Rather NAT provides for greater flexibility as well as a sort of built in security/privacy feature. Of course, some technical ideologues differ with this view of NAT. > So I suggest that a multi6 goal should be that the > thing an application gets back from an AAAA query, or any other source > including manual config, must be a permanent identifier with the > nice property that something below the socket API can transform it > into a locator. > > Which leads me to wonder whether session survival for sessions using > temporary things such as RFC 3041 addresses is a reasonable goal for > multi6. Wonderment is a bugger isn't it? > > > Brian Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From owner-multi6@ops.ietf.org Tue Jun 29 22:24:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15659 for ; Tue, 29 Jun 2004 22:24:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfUlK-000D1l-4c for multi6-data@psg.com; Wed, 30 Jun 2004 02:23:50 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfUlI-000D1M-AV for multi6@ops.ietf.org; Wed, 30 Jun 2004 02:23:49 +0000 Received: from gihz1.telstra.net (rsdhcp4.telstra.net [203.50.0.196]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id i5U2MHrA018649; Wed, 30 Jun 2004 12:22:17 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 30 Jun 2004 12:22:29 +1000 To: multi6@ops.ietf.org From: Geoff Huston Subject: revision of architecture draft is now published Cc: brc@zurich.ibm.com, kurtis@kurtis.pp.se In-Reply-To: <40E22D1B.8B52A674@ix.netcom.com> References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <40E22D1B.8B52A674@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk draft-huston-multi6-architectures-01.txt has been published by the drafts editor. This version integrates comments made by working group members on the -00 version and also includes material proposed in the interim multi6 working group meeting earlier this month. I would like to propose to the chairs that the working group consider: - that this document be adopted as a working group document, and - that the appendix of this document be split off from the main text of the document and separately developed as a working group document. thanks. From owner-multi6@ops.ietf.org Wed Jun 30 04:25:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01501 for ; Wed, 30 Jun 2004 04:25:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfaO7-0005NF-M1 for multi6-data@psg.com; Wed, 30 Jun 2004 08:24:15 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfaO6-0005N0-K4 for multi6@ops.ietf.org; Wed, 30 Jun 2004 08:24:14 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5U8Pd2r020642; Wed, 30 Jun 2004 10:25:39 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: cb64 Date: Wed, 30 Jun 2004 10:24:12 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 29-jun-04, at 10:43, Erik Nordmark wrote: > But the protocol can still defer the public key operations until the > first > locator change as far as I can tell. But then this locator change wouldn't be protected by the key, so what's the point of having it? To provide proof that the third locator belongs to the same entity as the second locator? I think it's essential to exchange _something_ that allows the other side to recognize its correspondent after a rehoming event before such a rehoming event happens (for the first time). Still, this doesn't have to be a very heavy-weight thing: transmitting some kind of hash would be enough, later this hash value can be used to authenticate a full key or hash chain. A good way to do this is would probably be in an extension header or end-to-end option in one of the early packets (not in the first one because it will delay session establishment if a firewall rejects the packet with the option, and we don't want to create state before return routability is established to avoid being too easily DoSable). From owner-multi6@ops.ietf.org Wed Jun 30 04:46:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02656 for ; Wed, 30 Jun 2004 04:46:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfahA-0007bU-Iz for multi6-data@psg.com; Wed, 30 Jun 2004 08:43:56 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfah9-0007bF-8c for multi6@ops.ietf.org; Wed, 30 Jun 2004 08:43:55 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i5U8jL2r020985; Wed, 30 Jun 2004 10:45:21 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9E90FBBC-CA71-11D8-9359-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: identifiers and security Date: Wed, 30 Jun 2004 10:43:54 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 29-jun-04, at 14:04, Erik Nordmark wrote: >>> and whether those IDs are visible to the applications. >> Ah, but that's a very different issue. I think by definition the >> identifiers are visible to the application. > My choice of "visible" doesn't capture the distinction I wanted to > make. Sorry. > What I mean was whether the applications need to do something > different because there is an ID (versus there just being a plain-old > IPv6 > address). The IDs can be visible, either by being part of an IPv6 > locator, > or by some new mechanism by which the application can ask the stack > for the ID, > but that wasn't the point I was trying to make. Ok. >>> Taking NOID as an example of with no new ID namespace, the amount of >>> work (in the form of DNS lookups in forward and reverse maps) >>> will also result in stronger association between FQDNs and locators >>> than we have today. >> Even if we assume DNSSEC? > Assume DNSSEC for the baseline (current Internet), for NOID, or for > both > when comparing them? Compare NOID without DNSSEC with DNSSEC without NOID. I think the latter provides stronger FQDN -> address and address -> FQDN information although you are right that this isn't the same as FQDN <-> address. >>> I've received pushback from folks that I wouldn't characterize as >>> security geeks, that this would be too weak. >> I don't think this is universally true. Certainly, this is too weak >> for >> TLS or IPsec sessions that can now be broken by an attacker, unlike >> before. But why would this be too weak for talking to Google over >> unprotected TCP/IP? > If I recall correctly, the main concern is when attackers and nodes > move > around. > In today's if an attacker is on the path it can cause damage to the > communication if the communication isn't protected with something like > IPsec > or TLS. But this ability to cause damage is limited to the time period > while > the attacker is on the path. > If we add some multihoming signaling whereby an attacker, which was on > the path (e.g., by being on the same WiFi subnet as the victim) for a > short > time period, can cause damage by essentially using the state creation > as a way to preserve it's on-path'ness forever, then folks are > concerned. And justifyably so. But wouldn't it be possible to address this in other ways? Such as having per-direction or even per-session state rather than per-address? > But what you brought to the table is that if we can ensure that > secured traffic > can not be redirected, by reusing the keys or otherwise "layering" on > top of > IPsec or TLS, then at least we would know that secured traffic could > never be > redirected by an attacker. So security-wise we'd gain some and loose > some. I think if the redirection problem by attackers that are on-path temporarily is limited to individual unprotected sessions, we are not materially worse off than today as the same attacker could break the sessions today also, and redirecting an unprotected session presumably isn't worse than breaking it as the contents aren't secret. >> I'm thinking more along the line of violating layers and modify >> IPsec/TLS >> such that the wedge or modified IP can obtain keys that are exchanged >> by modified IPsec/TLS. Something like putting the secret instructions >> for the messager in the locked briefcase he's carrying. This works >> well >> except for the first trip of course... > This sounds tricky. :-) > I guess I don't know enough how the TLS keys (and which > keys; is there some master key used to generate the RC4 key?, etc) > can be exported from TLS. I don't know the specs by heart but the way I understand it is that you have a public/private keypair for at least one end of the connection. This key pair is used to create a session key which is subsequently used for encryption. The same key or maybe a different one is used for authentication. TLS works with blocks that may span several TCP segments. Since there is significant housekeeping, I'm assuming it would be possible to define a new message type that can be exchanged between the two hosts without getting in the way of existing operation (negotiation or data transfer). All that would need to happen here is for each side to announce a session key that can be used for multihoming to the other side. Since this information is encrypted, signed and delivered over reliable transport, there isn't much more to it. It would of course also be possible to use TLS's own session key, but that's probably dangerous as it may more easily leak and that key is subject to renegotiation. > FWIW Doing the insecure signaling protocol for managing the contexts > is something I can do; a version of such a spec can be created by > taking the > NOID spec and removing the places where it verifies things in the DNS. > Saying it is layered above IPsec is also easy to say, but the > difficulty > is exploring the interaction with IPsec and IKE, as well as TLS. Right. What did you think about my IPsec/TLS/DNS musings? This would provide pretty much the above using unmodified NOID. The IPsec/TLS stuff doesn't get easier this way but it's more modular and it also has other benefits (can do TLS when the DNS is down, at least in theory) so it may be easier to get off the ground. From owner-multi6@ops.ietf.org Wed Jun 30 05:02:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03248 for ; Wed, 30 Jun 2004 05:02:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfayE-0009bk-FW for multi6-data@psg.com; Wed, 30 Jun 2004 09:01:34 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfayB-0009b9-QR for multi6@ops.ietf.org; Wed, 30 Jun 2004 09:01:33 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id EDF8D2A304; Wed, 30 Jun 2004 11:01:30 +0200 (CEST) Received: from [163.117.139.233] (unknown [163.117.139.233]) by smtp03.uc3m.es (Postfix) with ESMTP id D5D802A300; Wed, 30 Jun 2004 11:01:30 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <3725F22A-CA74-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Multi6 , Erik Nordmark From: marcelo bagnulo braun Subject: Re: cb64 Date: Wed, 30 Jun 2004 11:02:29 +0200 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Iljitsch, El 30/06/2004, a las 10:24, Iljitsch van Beijnum escribi=F3: > On 29-jun-04, at 10:43, Erik Nordmark wrote: > >> But the protocol can still defer the public key operations until the=20= >> first >> locator change as far as I can tell. > > But then this locator change wouldn't be protected by the key, so=20 > what's the point of having it? To provide proof that the third locator=20= > belongs to the same entity as the second locator? > We are considering cb64, which is some form of cga, so the iid of the=20 locator is derived from a hash of the public key (and some other stuff) So, when only a single locator is being used, you are essentially in=20 the current single address situation so there is no need to add any=20 security. You need additional security when you add a new alternative locator. As you mention, you need some way to prove that the new locator belongs=20= to the owner of the initial address (which is being used as ULP=20 identifier) In order to do that, when you send the new locator, you send the public=20= key (pk) and some form of signed string (in order to prove that you=20 have the private key associated with pk) So, the receiver verifies that the iid of the initial address matches=20 with the hash of the public key, so you link pk with the ULP id. Then by verifying that the signed string can be deciphered with the pk,=20= you know that the new locator was added by the owner of the ULP id Of course you still need to ping the locator in order to avoid=20 flooding, but this is another story > I think it's essential to exchange _something_ that allows the other=20= > side to recognize its correspondent after a rehoming event before such=20= > a rehoming event happens (for the first time). Still, this doesn't=20 > have to be a very heavy-weight thing: transmitting some kind of hash=20= > would be enough, later this hash value can be used to authenticate a=20= > full key or hash chain. yes, the hash is contained in the initial address, since it is a cga > A good way to do this is would probably be in an extension header or=20= > end-to-end option in one of the early packets (not in the first one=20 > because it will delay session establishment if a firewall rejects the=20= > packet with the option, it is already contained in address field regards, marcelo > and we don't want to create state before return routability is=20 > established to avoid being too easily DoSable). > > From owner-multi6@ops.ietf.org Wed Jun 30 08:27:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13148 for ; Wed, 30 Jun 2004 08:27:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bfe9q-0004uu-5V for multi6-data@psg.com; Wed, 30 Jun 2004 12:25:46 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfe9o-0004ud-ET for multi6@ops.ietf.org; Wed, 30 Jun 2004 12:25:45 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5UCPgFA123264; Wed, 30 Jun 2004 12:25:42 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5UCPfXi151066; Wed, 30 Jun 2004 14:25:41 +0200 Received: from zurich.ibm.com (sig-9-145-245-202.de.ibm.com [9.145.245.202]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA75990; Wed, 30 Jun 2004 14:25:40 +0200 Message-ID: <40E2B13C.1090002@zurich.ibm.com> Date: Wed, 30 Jun 2004 14:25:32 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: multi6@ops.ietf.org CC: Geoff Huston , kurtis@kurtis.pp.se Subject: Q1 Re: revision of architecture draft is now published References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <40E22D1B.8B52A674@ix.netcom.com> <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> In-Reply-To: <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Geoff, thanks. Because of the way our charter is currently written, we have two separate questions to the WG. Here is the first one: Do people agree to adopt this draft as a WG draft (which means that the next update will be draft-ietf-multi6-architectures-00.txt)? That doesn't mean you have to agree that it's perfect, just that it is a good basis for a WG deliverable. Please answer this question without worrying whether the Appendix is split off, and please respond by July 9th. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM Geoff Huston wrote: > draft-huston-multi6-architectures-01.txt has been published by the drafts editor. This version integrates comments made by working group members on the -00 version and also includes material proposed in the interim multi6 working group meeting earlier this month. > > I would like to propose to the chairs that the working group consider: > > - that this document be adopted as a working group document, and > > - that the appendix of this document be split off from the main text of the document and separately developed as a working group document. > > > thanks. > > > > From owner-multi6@ops.ietf.org Wed Jun 30 08:28:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13192 for ; Wed, 30 Jun 2004 08:28:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfeCM-0005Bb-NA for multi6-data@psg.com; Wed, 30 Jun 2004 12:28:22 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfeCL-0005BE-Kh for multi6@ops.ietf.org; Wed, 30 Jun 2004 12:28:22 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5UCSKFA109756; Wed, 30 Jun 2004 12:28:20 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5UCSJXi173104; Wed, 30 Jun 2004 14:28:19 +0200 Received: from zurich.ibm.com (sig-9-145-245-202.de.ibm.com [9.145.245.202]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA86548; Wed, 30 Jun 2004 14:28:18 +0200 Message-ID: <40E2B1DB.9090205@zurich.ibm.com> Date: Wed, 30 Jun 2004 14:28:11 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Geoff Huston CC: multi6@ops.ietf.org, kurtis@kurtis.pp.se Subject: Q2 Re: revision of architecture draft is now published References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <40E22D1B.8B52A674@ix.netcom.com> <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> In-Reply-To: <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit And here is the second question: Do people think the Appendix to this draft, which is a preliminary analysis of various proposed approaches, should become a separate document? If the answer is yes, we have to discuss with our Area Director how this would fit into the WG charter. Brian Geoff Huston wrote: > draft-huston-multi6-architectures-01.txt has been published by the drafts editor. This version integrates comments made by working group members on the -00 version and also includes material proposed in the interim multi6 working group meeting earlier this month. > > I would like to propose to the chairs that the working group consider: > > - that this document be adopted as a working group document, and > > - that the appendix of this document be split off from the main text of the document and separately developed as a working group document. > > > thanks. > > > > From owner-multi6@ops.ietf.org Wed Jun 30 09:40:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16960 for ; Wed, 30 Jun 2004 09:40:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BffIv-000D0b-2m for multi6-data@psg.com; Wed, 30 Jun 2004 13:39:13 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BffIt-000D0F-W1 for multi6@ops.ietf.org; Wed, 30 Jun 2004 13:39:12 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5UDd6J6000495; Wed, 30 Jun 2004 06:39:08 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5UDd1208474; Wed, 30 Jun 2004 15:39:02 +0200 (MEST) Date: Wed, 30 Jun 2004 06:36:35 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-nordmark-multi6-threats-01.txt To: marcelo bagnulo braun Cc: Erik Nordmark , Multi6 List In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > that was not my intention. i am assuming that it is worse that an > attacker hijacks all the present and future communications than just > hijacking a single connection. So, a single communication requires less > security than all the present and future communications in one > direction which in turns requires less security that all present and > future communication communications in both directions. > > I mean, if a single communication is at stake the solution needs less > security than when all the communications are at stake. But that is a weak statement about uniformity. If a host has 1 communication which is used to sound the fire alarm, plus lots of communications which provide rather unimportant statistics, I would argue that the single "fire alarm" communication is as important as all the communication that host performs. > I guess that different apps will have different security requirements. > However, i am considering the default scenario here. I mean the multi6 > solution will provide some default level of security based on some > security tools used by the solution. > If a particular communication requires additional security, it will > obtain it by special means (TLS for instance) But TLS wouldn't by itself prevent a weakness in the multihoming layer being used to redirect the packets to a black hole; neither would IPsec when IPsec is layer above the multihoming layer. Erik From owner-multi6@ops.ietf.org Wed Jun 30 10:17:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19764 for ; Wed, 30 Jun 2004 10:17:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfftN-000H6Y-18 for multi6-data@psg.com; Wed, 30 Jun 2004 14:16:53 +0000 Received: from [131.160.193.2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfftL-000H6I-ED for multi6@ops.ietf.org; Wed, 30 Jun 2004 14:16:51 +0000 Received: from nomadiclab.com (n45.nomadiclab.com [131.160.193.45]) by n2.nomadiclab.com (Postfix) with ESMTP id 88AFA2130FF; Wed, 30 Jun 2004 17:16:50 +0300 (EEST) Message-ID: <40E2CB0E.3080501@nomadiclab.com> Date: Wed, 30 Jun 2004 17:15:42 +0300 From: Jukka Ylitalo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Cc: Erik Nordmark , marcelo bagnulo braun , Multi6 List Subject: Re: about Wedgelayer 3.5 / Fat IP approaches References: <6938661A6EDA8A4EA8D1419BCE46F24C04060720@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060720@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Henderson, Thomas R wrote: > >Rather than NOID kind of split, maybe CB64-like split is preferable? >(where lower bits of AID match the HIT and upper bits the prefix, >rather than having the AID be unrelated to the HIT)? It wouldn't >have to be a /64 split necessarily-- just reverse mappable with >DNSSEC. I agree that HIP opportunistic mode should be able to >deal with it. > > CB64 -like split sounds good. Right, there arises some AID ownership problems if it is not bound to the HIT. It would be nice to have a new version of Multi6 HIP draft that describes how HIP could be used with CB64 -like AIDs. >Already in HIP there has been some struggle with what AID to pass >to applications, and some level of discomfort with passing non >routable values posing as IP addresses to legacy apps, for many of >the reasons cited in the previous posts (see also Appendix A of >the draft HIP base spec). For legacy APIs and legacy apps, then, >maybe this kind of AID/m6 identifier split could satisfy >the referral issue, or perhaps instead being underpinned by WIMP >or other lighter-weight m6 identifier, as you and Erik suggest. > >Tom > > > > I have concentrated on the ephemeral identifiers concept and tried to figure out their properties in different scenarios. The ephemeral identifiers are useful with one-way hash chain authentication, when establishing a state. An attacker cannot easily steal a context identifier in this way. However, because the presented ephemeral namespace is flat and not routable from its nature, it does not solve the referral problem. Now, if we conceptually separate AIDs from wedge 3.5 layer Context Identifiers (let them be called as CIDs), we still end up with AID ownership problems. The security problems related to wedge layer context theft and application layer identifier theft are slightly different, but they are mostly similar with each other. What comes to the current WIMP work, is that we are making an exercise to understand the relationship between routable AIDs, ephemeral CIDs, and hash chains. I like to notice that the work is not the final editorial effort to combine group-F protocols as requested by co-chairs. Before that, we should start naming the different components in different group-F proposals, and evaluate the components against the things-to-think-about and security-threats drafts, if possible. At this point of time, while our exercise is still under work, I have a feeling that a routable AID should have cryptographical properties that can be used to prove the ownership of that AID; if we do not want to rely on the DNS. The properties are based on the public key cryptography. [In any case, I try to finish the exercise with hash chains etc. before my summer vacation starts :-) br, Jukka From owner-multi6@ops.ietf.org Wed Jun 30 10:41:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21289 for ; Wed, 30 Jun 2004 10:41:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfgGL-000JKv-L4 for multi6-data@psg.com; Wed, 30 Jun 2004 14:40:37 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfgGJ-000JKQ-Ue for multi6@ops.ietf.org; Wed, 30 Jun 2004 14:40:36 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1C67029E54; Wed, 30 Jun 2004 16:40:35 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp03.uc3m.es (Postfix) with ESMTP id 02DA729E43; Wed, 30 Jun 2004 16:40:35 +0200 (CEST) In-Reply-To: <40E2CB0E.3080501@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060720@xch-nw-27.nw.nos.boeing.com> <40E2CB0E.3080501@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <960697AC-CAA3-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: "Henderson, Thomas R" , Multi6 List , Erik Nordmark From: marcelo bagnulo braun Subject: Re: about Wedgelayer 3.5 / Fat IP approaches Date: Wed, 30 Jun 2004 16:41:35 +0200 To: Jukka Ylitalo X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 30/06/2004, a las 16:15, Jukka Ylitalo escribi=F3: > Hi, > > Henderson, Thomas R wrote: > >> >> Rather than NOID kind of split, maybe CB64-like split is preferable? >> (where lower bits of AID match the HIT and upper bits the prefix, >> rather than having the AID be unrelated to the HIT)? It wouldn't >> have to be a /64 split necessarily-- just reverse mappable with >> DNSSEC. I agree that HIP opportunistic mode should be able to deal=20= >> with it. >> > CB64 -like split sounds good. Right, there arises some AID > ownership problems if it is not bound to the HIT. > It would be nice to have a new version of Multi6 HIP draft that > describes how HIP could be used with CB64 -like AIDs. > how this would differ from the cb64 draft by Erik? >> Already in HIP there has been some struggle with what AID to pass >> to applications, and some level of discomfort with passing non >> routable values posing as IP addresses to legacy apps, for many of=20 >> the reasons cited in the previous posts (see also Appendix A of >> the draft HIP base spec). For legacy APIs and legacy apps, then,=20 >> maybe this kind of AID/m6 identifier split could satisfy >> the referral issue, or perhaps instead being underpinned by WIMP >> or other lighter-weight m6 identifier, as you and Erik suggest. >> >> Tom >> >> >> > I have concentrated on the ephemeral identifiers concept and > tried to figure out their properties in different scenarios. > The ephemeral identifiers are useful with one-way > hash chain authentication, when establishing a state. > An attacker cannot easily steal a context identifier in this way. > > However, because the presented ephemeral namespace is flat > and not routable from its nature, it does not solve the referral > problem. Now, if we conceptually separate AIDs from wedge 3.5 > layer Context Identifiers (let them be called as CIDs), we still end > up with AID ownership problems. The security problems related > to wedge layer context theft and application layer identifier theft > are slightly different, but they are mostly similar with each other. > > What comes to the current WIMP work, is that we are making > an exercise to understand the relationship between routable AIDs, > ephemeral CIDs, and hash chains. I like to notice that the work is > not the final editorial effort to combine group-F protocols as=20 > requested > by co-chairs. Before that, we should start naming the different=20 > components > in different group-F proposals, and evaluate the components against = the > things-to-think-about and security-threats drafts, if possible. > > At this point of time, while our exercise is still under work, I have > a feeling that a routable AID should have cryptographical properties > that can be used to prove the ownership of that AID; if we do not want > to rely on the DNS. The properties are based on the public key=20 > cryptography. yes, that is my conclusion so far, so you end up in cb64 or similar=20 afaics regards, marcelo > [In any case, I try to finish the exercise with hash chains etc.=20 > before my summer > vacation starts :-) > > br, Jukka > From owner-multi6@ops.ietf.org Wed Jun 30 10:42:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21337 for ; Wed, 30 Jun 2004 10:42:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfgG9-000JIr-KN for multi6-data@psg.com; Wed, 30 Jun 2004 14:40:25 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfgG5-000JHx-MH for multi6@ops.ietf.org; Wed, 30 Jun 2004 14:40:24 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A2B4E29E43; Wed, 30 Jun 2004 16:40:20 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp03.uc3m.es (Postfix) with ESMTP id 8A20729D29; Wed, 30 Jun 2004 16:40:20 +0200 (CEST) In-Reply-To: <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <40E22D1B.8B52A674@ix.netcom.com> <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8D58C314-CAA3-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: kurtis@kurtis.pp.se, multi6@ops.ietf.org, brc@zurich.ibm.com From: marcelo bagnulo braun Subject: Re: revision of architecture draft is now published Date: Wed, 30 Jun 2004 16:41:20 +0200 To: Geoff Huston X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Geoff, El 30/06/2004, a las 4:22, Geoff Huston escribi=F3: > draft-huston-multi6-architectures-01.txt has been published by the=20 > drafts editor. This version integrates comments made by working group=20= > members on the -00 version and also includes material proposed in the=20= > interim multi6 working group meeting earlier this month. > > I would like to propose to the chairs that the working group consider: > > - that this document be adopted as a working group document, and > > - that the appendix of this document be split off from the main text=20= > of the document and separately developed as a working group document. > > > thanks. > Some comments about the draft: - About MIPv6: imho we have an important thing to learn from mipv6 (in=20= its current form) which is that return routability type of mechanisms=20 are not suitable to address the multihoming problem. this is a=20 fundamental problem, because in mipv6 the identifier ownership is=20 proven by periodical reachability tests. Considering that multihoming=20 deals with outages, the reachability tests will fail when there is a=20 failure. the periodicity of the tests is required to avoid attacks=20 shifted in time - About traffic engineering: imho is within the scope of a multihoming=20= solution, since i think TE are included among the goals stated in RFC=20 3582. In particular 3.1.2. Load Sharing By multihoming, a site should be able to distribute both inbound and outbound traffic between multiple transit providers. This goal is for concurrent use of the multiple transit providers, not just the usage of one provider over one interval of time and another provider over a different interval. and also: 3.1.4. Policy A customer may choose to multihome for a variety of policy reasons beyond technical scope (e.g., cost, acceptable use conditions, etc.) For example, customer C homed to ISP A may wish to shift traffic of = a certain class or application, NNTP, for example, to ISP B as matter of policy. A new IPv6 multihoming proposal should provide support for site-multihoming for external policy reasons. So, i guess that a multihoming solution should try to provide these=20 goals, and imho an analysis of the solution space should consider these=20= items. - About section 2. imho this section has improved in this version and now provides a more=20= general approach, since it explicitly addresses both the site=20 visibility, the session resilience cases and also TE stuff. However,=20 perhaps it would be interesting to also include the case when the=20 internal hosts attempt to initiate a communication after a failure? I mean, when a failure occurs, there are three situations to be=20 considered, imho. first, session resilience, second that an external=20 host is capable of establishing new communications with multihomed=20 hosts, and third that a multihomed host is capable of establishing new=20= communications with external hosts after the outage, i think that the=20 last case is missing. - about section 4.2 where it states that: "The implication here is that if the local host wishes to maintain a session across such events it needs to communicate to remote host R that it is possible to switch to using a destination address for the multi-homed host that is = based on ISP B' address prefix." i think that the implication here applies both to established=20 communications and to new ones Additionally i am not sure that it is required that the local host=20 informs R about the available locators. As Brian said once (if i=20 remeber correctly), the local host is the last one to find out that one=20= of its own locators in no longer working. IMHO what is needed is that R=20= discovers which is the new locator to use So, i would rephrase it into something like: The implication here is that in order to enable the communication between R and the local host across such events, the remote host R=20= has to discover that it has to use a destination address for the multi-homed host that is=20= based on ISP B' address prefix. (but if you understand my concerns, you can rephrase it much better=20 than this, i guess :-) - about section 4.4 at the end of the first paragraph it is stated than: "This modification could be undertaken within the transport protocol stack element, or within the internetworking stack element. The functional outcome from these modifications would be to create a mechanism to support the use of multiple locators within the context of a single = endpoint-to-endpoint session." i am not sure that session would be appropriate for the IP layer...=20 perhaps replacing session with "communication"? From owner-multi6@ops.ietf.org Wed Jun 30 11:18:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23500 for ; Wed, 30 Jun 2004 11:18:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfgqH-000NnX-FS for multi6-data@psg.com; Wed, 30 Jun 2004 15:17:45 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfgqG-000Nn6-3N for multi6@ops.ietf.org; Wed, 30 Jun 2004 15:17:44 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5UFHgGm084350 for ; Wed, 30 Jun 2004 15:17:42 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5UFHgXi181342 for ; Wed, 30 Jun 2004 17:17:42 +0200 Received: from zurich.ibm.com (sig-9-145-245-135.de.ibm.com [9.145.245.135]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA78184 for ; Wed, 30 Jun 2004 17:17:41 +0200 Message-ID: <40E2D98E.2010504@zurich.ibm.com> Date: Wed, 30 Jun 2004 17:17:34 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 List Subject: Re: Next steps References: <2E5BF43F-BEEE-11D8-B677-000A95928574@kurtis.pp.se> <40E15569.9050005@zurich.ibm.com> <40E1781F.4060508@psc.edu> In-Reply-To: <40E1781F.4060508@psc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit That isn't the plan, unless the authors choose to do so, but some of these drafts fit into the wedge layer or components class, so I would expect those to be updated or morphed. Brian Michael Lambert wrote: > The following all appear to be expired drafts (at least they are not > current in the IETF ID repository): > >> draft-ohta-multihomed-isps-00.txt >> draft-ohira-assign-select-e2e-multihome-01.txt (and -02 as well) >> draft-van-beijnum-multi6-isp-int-aggr-01.txt >> draft-py-multi6-mhtp-01.txt >> draft-huitema-multi6-experiment-00.txt >> draft-ohta-e2e-multihoming-05.txt >> draft-nordmark-multi6-cb64-00.txt >> draft-nordmark-multi6-noid-01.txt >> draft-crocker-mast-proposal-01.txt >> draft-de-launois-multi6-naros-00.txt > > > Do the authors have plans to revise and resubmit? > > Michael > From owner-multi6@ops.ietf.org Wed Jun 30 11:46:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24838 for ; Wed, 30 Jun 2004 11:46:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfhHZ-0000Rz-NU for multi6-data@psg.com; Wed, 30 Jun 2004 15:45:57 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfhHW-0000Re-Ga for multi6@ops.ietf.org; Wed, 30 Jun 2004 15:45:54 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B465B2A018; Wed, 30 Jun 2004 17:45:53 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp03.uc3m.es (Postfix) with ESMTP id 9D58129FBE; Wed, 30 Jun 2004 17:45:53 +0200 (CEST) In-Reply-To: <40E2DC40.1050909@zurich.ibm.com> References: <40E1575A.9010709@zurich.ibm.com> <8E1939A4-C9D8-11D8-A131-000D93ACD0FE@it.uc3m.es> <40E2DC40.1050909@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Jukka Ylitalo , Multi6 List , Erik Nordmark From: marcelo bagnulo braun Subject: Re: about Wedgelayer 3.5 / Fat IP approaches Date: Wed, 30 Jun 2004 17:46:53 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 30/06/2004, a las 17:29, Brian E Carpenter escribi=F3: >>> >>> CGAs have other downsides for multihoming, too. >>> >> such as? > > > > > I really don't want to start a discussion here about cryptographic > strength, but my objection to CGAs in the multi6 context is that they > include the /48 prefix in the hash, and that is variable in multi6, > which means that the host ID changes when you change prefix. I think > that's an unfortunate property because it eliminates some possible > tricks in the ID/locator split. > Well, probably it is my fault for using the wrong terminology, but i=20 was considering cgas as a concept rather than the specific approach=20 followed by the send wg. for instance you can consider the cb64 draft or even the ideas=20 discussed between Iljitsch and Jari about including all the prefixes or=20= some other workarounds. My point was basically that having a string that it can be used as a=20 valid locator and that it also has a crypto nature would provide=20 several benefits, since it enables a way to prove its ownership and=20 apps can treat it as a regular ip address Makes more sense? regards, marcelo PS: it is clear that if we are going to use one locator as ULP id, the=20= id will have to change when renumbering, the benefit of this, is that=20 apps still handle ip addresses and that most of their assumptions still=20= hold. > Brian > From owner-multi6@ops.ietf.org Wed Jun 30 12:12:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26736 for ; Wed, 30 Jun 2004 12:12:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfhhF-0004We-6p for multi6-data@psg.com; Wed, 30 Jun 2004 16:12:29 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfhhC-0004Va-Av for multi6@ops.ietf.org; Wed, 30 Jun 2004 16:12:26 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5UFTMGP079364; Wed, 30 Jun 2004 15:29:22 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5UFTH72206226; Wed, 30 Jun 2004 17:29:17 +0200 Received: from zurich.ibm.com (sig-9-145-245-135.de.ibm.com [9.145.245.135]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA88648; Wed, 30 Jun 2004 17:29:11 +0200 Message-ID: <40E2DC40.1050909@zurich.ibm.com> Date: Wed, 30 Jun 2004 17:29:04 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: marcelo bagnulo braun CC: Jukka Ylitalo , Multi6 List , Erik Nordmark Subject: Re: about Wedgelayer 3.5 / Fat IP approaches References: <40E1575A.9010709@zurich.ibm.com> <8E1939A4-C9D8-11D8-A131-000D93ACD0FE@it.uc3m.es> In-Reply-To: <8E1939A4-C9D8-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit marcelo bagnulo braun wrote: > > El 29/06/2004, a las 13:49, Brian E Carpenter escribió: > >> Eik Nordmark wrote: >> >>>> what about cgas? >>>> They are locators, so you can use them for refferals to non multi6 >>>> apps and hosts, they allow to map from id to locators using reverse >>>> dns, and they are crypto in nature >>>> seems a good candidate to me :-) >>> >>> A downside of CGA approaches is that they would, on a global basis, >>> cast the /64 subnet prefix boundary in stone forever. >>> This is different than SeND which only assumes the /64 on a single link, >>> and one can envision SeND evolving to handle different subnet prefix >>> lengths >>> over time. >>> Different people probably have very different level of concern for >>> "/64 forever in stone" ranging from it being a good simplification >>> to a fatal repeat of the 8 bit IPv4 network number + 24 bit host number >>> (before Class B and C was invented). >> >> >> Good point. The /64 boundary is only "architectural" in one place, >> stateless >> autoconfig, and even that is a changeable decision. >> >> CGAs have other downsides for multihoming, too. >> > > such as? I really don't want to start a discussion here about cryptographic strength, but my objection to CGAs in the multi6 context is that they include the /48 prefix in the hash, and that is variable in multi6, which means that the host ID changes when you change prefix. I think that's an unfortunate property because it eliminates some possible tricks in the ID/locator split. Brian From owner-multi6@ops.ietf.org Wed Jun 30 12:55:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28727 for ; Wed, 30 Jun 2004 12:55:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfiL5-0008dH-2R for multi6-data@psg.com; Wed, 30 Jun 2004 16:53:39 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfiL2-0008cV-Tz for multi6@ops.ietf.org; Wed, 30 Jun 2004 16:53:37 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C6B3A276CA; Wed, 30 Jun 2004 18:53:35 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp02.uc3m.es (Postfix) with ESMTP id ACBFF276BF; Wed, 30 Jun 2004 18:53:35 +0200 (CEST) In-Reply-To: <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <40E22D1B.8B52A674@ix.netcom.com> <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <2ABC09C2-CAB6-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: kurtis@kurtis.pp.se, multi6@ops.ietf.org, brc@zurich.ibm.com From: marcelo bagnulo braun Subject: 2nd part Re: revision of architecture draft is now published Date: Wed, 30 Jun 2004 18:54:35 +0200 To: Geoff Huston X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable The first mail was unintentionally sent, so i include the remaining=20 comments here. - about section 4.5 I am not sure about the following comment: "Packet header rewriting by remote network elements has a large = number of associated considerations, and documentation relating to the considerations of the use of Network Address Translators [4] = contains much of this material." I mean, if the multi6 layer within the host replaces the received=20 locator by the ULP identifier, then it doesn't really matter the=20 locator than was actually carried in the packet, right? I mean, in any=20= case, the locator is transparent to the ULP which only deals with the=20 identifier. Moreover, perhaps replacing locators by identifiers introduce some of=20 the nat problems, but in any case, i don't see how this related to the=20= fact that the locator is replaced by the host or by the edge router. So=20= perhaps some comment like this one is required but imho is not=20 restricted to this section but to all mechanisms that replace locators=20= by identifiers. Perhaps you were considering other issues here? - about section 5.1 i fail to understand the case you are describing with: It is also possible to allow the endpoint identity and locator space to overlap, and distinguish between the two identity realms by the context of usage rather than by a prefix comparison. However, this reuse of the locator token space as identity tokens has the = potential to create the anomalous situation where a particular locator value = is used as an identity value by a different endpoint. It is not clear that the identity and locator contexts can be clearly disambiguated in every case, which is a major drawback to this particular = approach. In particular which is the difference between this case and the "home"=20= locator case? Later in this section (the last paragraph, actually) it is stated that: Instead of structured tokens that double as lookup keys to obtain mappings from endpoint identities to locator sets, the alternative = is to use an unstructured token space, where individual token values = are drawn opportunistically for use within a multi-homed session = context. Here the semantics of the endpoint identity are subtly changed. The endpoint identity is not a persistent alias or reference to the identity of the endpoint, but a means to allow the identity protocol element to confirm that two locators are part of the same mapped locator set for a remote endpoint. In this context the unstructured opportunistic endpoint identifier values are used in determining locator equivalence rather than in some form of lookup function. i think that it is also possible to use an unstructured identifier name=20= space in a non opportunistic mode, like HIP, that supports both modes.=20= I mean, the identifier in this case is persistent, but as the address=20 space is not structured, lookups are at least difficult if not=20 impossible in the short term. So perhaps it would be interesting to split this paragraph in two, one=20= about unstructured namespaces, and another one about using them in a=20 opportunistic manner? - in section 5.3.2 where it states that: One of the potential drawbacks of placing this functionality within the transport protocol layer is that it is possible that each transport protocol will require a distinct implementation of = identity functionality. i would add that another drawback is that some transport layers (such=20 as UDP) don't have the notion of session neither, so in this case i=20 guess only the app knows about sessions - in section 5.3.3 when considering opportunistic identifiers to initiate the=20 communication. note that non of the proposals AFAIK, use opportunistic identifiers for=20= the server side. imho this is very difficult, because, the client side=20= needs to know the identifier in order to initiate the communication. It=20= would be possible that the client side would select the servers=20 identity beforehand, but this may imply collisions if the server is=20 already using it. imho opportunistic ids are only suitable for clients=20= (if any), but not for servers. - section 6.1 when it states that Does the transport need to translate the upper level interface token into an identity token that identifies the session? i guess that is not the transport who does the translation but it can=20 also be the wedge layer then when it states that How does the session initiator establish that the remote end of the session can support the multi-homing version of the transport protocol? what do you mean by "the multihoming version of the transport=20 protocol"? i mean in the wedge layer approach, for instance, the=20 trasnport protocol is not multihoming capable, but the wedge layer is.=20= I think that perhaps this section should reffer more to a multi6=20 capable endpoint rather than a multi6 capable transport protocol Additionally, i guess that i would also include in this section=20 something about how does the endpoints discover the locator set=20 available for the other endpoint and how do they select the source and=20= destiantion locator. In other words, i think that a couple of functions=20= within the fucntional decomposition should be: * locator discovery * locator selection (both source and destination) for initial contact Regards, marcelo PS: sorry for the fragmentation of the comments :-( El 30/06/2004, a las 4:22, Geoff Huston escribi=F3: > draft-huston-multi6-architectures-01.txt has been published by the=20 > drafts editor. This version integrates comments made by working group=20= > members on the -00 version and also includes material proposed in the=20= > interim multi6 working group meeting earlier this month. > > I would like to propose to the chairs that the working group consider: > > - that this document be adopted as a working group document, and > > - that the appendix of this document be split off from the main text=20= > of the document and separately developed as a working group document. > > > thanks. > > > > From owner-multi6@ops.ietf.org Wed Jun 30 14:04:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02288 for ; Wed, 30 Jun 2004 14:04:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfjQb-000GHQ-81 for multi6-data@psg.com; Wed, 30 Jun 2004 18:03:25 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfjQa-000GH8-9X for multi6@ops.ietf.org; Wed, 30 Jun 2004 18:03:24 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA15021; Wed, 30 Jun 2004 11:03:09 -0700 (PDT) Received: from xch-nw-23p.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i5UI38P15075; Wed, 30 Jun 2004 13:03:08 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by xch-nw-23p.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 Jun 2004 11:02:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: about Wedgelayer 3.5 / Fat IP approaches Date: Wed, 30 Jun 2004 11:02:45 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060722@xch-nw-27.nw.nos.boeing.com> Thread-Topic: about Wedgelayer 3.5 / Fat IP approaches Thread-Index: AcResDnTc8J6qB/ERtShpje5FJ6MigAEn50Q From: "Henderson, Thomas R" To: "marcelo bagnulo braun" , "Jukka Ylitalo" Cc: "Multi6 List" , "Erik Nordmark" X-OriginalArrivalTime: 30 Jun 2004 18:02:45.0445 (UTC) FILETIME=[7222F750:01C45ECC] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Wednesday, June 30, 2004 7:42 AM > To: Jukka Ylitalo > Cc: Henderson, Thomas R; Multi6 List; Erik Nordmark > Subject: Re: about Wedgelayer 3.5 / Fat IP approaches >=20 >=20 >=20 > El 30/06/2004, a las 16:15, Jukka Ylitalo escribi=F3: >=20 > > Hi, > > > > Henderson, Thomas R wrote: > > > >> > >> Rather than NOID kind of split, maybe CB64-like split is=20 > preferable? > >> (where lower bits of AID match the HIT and upper bits the prefix, > >> rather than having the AID be unrelated to the HIT)? It wouldn't > >> have to be a /64 split necessarily-- just reverse mappable with > >> DNSSEC. I agree that HIP opportunistic mode should be=20 > able to deal=20 > >> with it. > >> > > CB64 -like split sounds good. Right, there arises some AID > > ownership problems if it is not bound to the HIT. > > It would be nice to have a new version of Multi6 HIP draft that > > describes how HIP could be used with CB64 -like AIDs. > > >=20 > how this would differ from the cb64 draft by Erik? >=20 So, assuming that HIP hosts started to use low order bits of the HIT in their locators, and then used such a locator as an AID, the main differences I see are in the use of/reliance on PK crypto in the context establishment handshakes, as well as IPsec reliance=20 (HIP relies on PK signings for handshakes, and relies on IPsec,=20 while CB64 relies on neither), and some of the basic protocol=20 mechanisms of the two proposals (which one might argue are just details): - CB64 handshake occurs in parallel with start of data transfer (actually, after first data packet has been sent), while HIP holds the first packet waiting for HIP handshake to complete (or possibly piggybacks it on the HIP exchange).=20 - CB64 uses flow IDs and locators as keys to find context state for the session, while HIP uses IPsec SPIs - CB64 adds new locator for peer upon discovering it as a source address in a packet (and issuing PK-signed challenge/response),=20 while HIP explicitly signals the new locator in a signed HIP=20 exchange. Another difference is length of the hash of the key, which may cause some subtle differences. With 64 bit IDs (or, strictly speaking, ID tags, since the public keys are the actual identifiers), we can provide an embedded stack name in the AID,=20 whereas with HITs, we can only provide a mapping between=20 (truncated) stack name and AIDs. When we have discussed=20 shortening HITs to accommodate some structure to aid reverse=20 lookups, there have been concerns raised that 64 bit IDs might=20 not be strong enough to withstand server farm attacks in the=20 future (generating different key that hashes to same ID). =20 If a larger hash is used as the identifier, then the AID with=20 truncated HIT can be viewed as a slightly less secure=20 identifier used for support of referrals for non-multi6/HIP=20 aware apps, which keeps the door open for future HIP-aware=20 apps to directly use the full IDs. Tom From owner-multi6@ops.ietf.org Wed Jun 30 14:32:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03988 for ; Wed, 30 Jun 2004 14:32:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfjsA-000JZa-G8 for multi6-data@psg.com; Wed, 30 Jun 2004 18:31:54 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfjs9-000JZN-Io for multi6@ops.ietf.org; Wed, 30 Jun 2004 18:31:53 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i5UIVd0R028978; Wed, 30 Jun 2004 11:31:39 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5UIVT207607; Wed, 30 Jun 2004 20:31:29 +0200 (MEST) Date: Wed, 30 Jun 2004 07:36:25 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: cb64 To: Iljitsch van Beijnum Cc: Erik Nordmark , Multi6 In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > But the protocol can still defer the public key operations until the > > first > > locator change as far as I can tell. > > But then this locator change wouldn't be protected by the key, so > what's the point of having it? To provide proof that the third locator > belongs to the same entity as the second locator? In cb64 as it was written it accepts the first peer locator (the one used to setup the state) on the faith of the return routability check implicit in establishing the state. When there is a locator change the peer have to prove itself using the CGA property i.e. public key crypto. My point is that having different IIDs for the different prefixes does not require a change to this way of doing things. > I think it's essential to exchange _something_ that allows the other > side to recognize its correspondent after a rehoming event before such > a rehoming event happens (for the first time). Yes, which is why my email said that the context would need to be identified at the receiver using only the flow label (compared to cb64 as written which uses flow label + IID). This *might* increase the desire to have something more than the 20 flow label bits identify the context, which would push us into having an extension header with a larger context tag. But I'm far from convinced this is required. Erik From owner-multi6@ops.ietf.org Wed Jun 30 14:32:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04032 for ; Wed, 30 Jun 2004 14:32:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfjsT-000Jc6-Td for multi6-data@psg.com; Wed, 30 Jun 2004 18:32:13 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfjsT-000Jbo-44 for multi6@ops.ietf.org; Wed, 30 Jun 2004 18:32:13 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i5UIW40R029143; Wed, 30 Jun 2004 11:32:04 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5UIVw207642; Wed, 30 Jun 2004 20:31:58 +0200 (MEST) Date: Wed, 30 Jun 2004 07:47:10 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Engaging apps folks To: Jeroen Massar Cc: Brian E Carpenter , Erik Nordmark , Iljitsch van Beijnum , Multi6 In-Reply-To: "Your message with ID" <1088517904.20311.175.camel@segesta.zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > A network application developer actually only wants this: > 8<--------- > char uri[] = "tcp://hostname:service"; > sock = uriconnect(uri); > -------->8 > > A function similar like that should be abstracted by the networking > API's. getaddrinfo() requires a loop, weird cases etc, which you have to > duplicate in every application. The above would simply work(tm) and > doesn't require the application developer to worry about anything > networkish. The socket now presented by the API is for the application > the identifier and the only thing the API (or most probably the kernel) > would now have to do is make bloody sure that it keeps working, even if > it has to change underlying addresses etc. uriconnect() can abstract all > of that, the socket(), getaddrinfo() loop and the connect() call. The above is easy and with slight variations exist in different higher level abstractions to access the network. I don't know if all those abstractions do the retry loop though. But that doesn't address UDP, which would require a different structure of the API because only the application knows when to retry (e.g., based on the application layer not getting a response). Hence the retry can't be hidden under the API for UDP. Erik From owner-multi6@ops.ietf.org Wed Jun 30 14:32:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04062 for ; Wed, 30 Jun 2004 14:32:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bfjsl-000JfT-5N for multi6-data@psg.com; Wed, 30 Jun 2004 18:32:31 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfjsj-000Jeq-Rg for multi6@ops.ietf.org; Wed, 30 Jun 2004 18:32:29 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5UIWSil023885 for ; Wed, 30 Jun 2004 12:32:28 -0600 (MDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5UIWO207680 for ; Wed, 30 Jun 2004 20:32:25 +0200 (MEST) Date: Wed, 30 Jun 2004 11:28:53 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Next steps To: Multi6 List In-Reply-To: "Your message with ID" <40E1781F.4060508@psc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > The following all appear to be expired drafts (at least they are not > current in the IETF ID repository): > > > draft-ohta-multihomed-isps-00.txt > > draft-ohira-assign-select-e2e-multihome-01.txt (and -02 as well) > > draft-van-beijnum-multi6-isp-int-aggr-01.txt > > draft-py-multi6-mhtp-01.txt > > draft-huitema-multi6-experiment-00.txt > > draft-ohta-e2e-multihoming-05.txt > > draft-nordmark-multi6-cb64-00.txt > > draft-nordmark-multi6-noid-01.txt > > draft-crocker-mast-proposal-01.txt > > draft-de-launois-multi6-naros-00.txt > > Do the authors have plans to revise and resubmit? I'm working on filling in some missing aspects of the signaling protocol in NOID, to make sure this piece is complete. (I received comments way back about it being underspecified for instance when both ends initiate establishing state at the same time and taring down the state). I view this not as "pushing" for noid as a proposal, but instead making sure we have a worked out signaling protocol as a component that could be applied elsewhere. Erik From owner-multi6@ops.ietf.org Wed Jun 30 14:32:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04097 for ; Wed, 30 Jun 2004 14:32:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bfjst-000JhH-5J for multi6-data@psg.com; Wed, 30 Jun 2004 18:32:39 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfjsk-000JfB-9F for multi6@ops.ietf.org; Wed, 30 Jun 2004 18:32:30 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i5UIUN53024857; Wed, 30 Jun 2004 12:30:24 -0600 (MDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i5UIWA207648; Wed, 30 Jun 2004 20:32:13 +0200 (MEST) Date: Wed, 30 Jun 2004 07:52:16 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: identifiers and security To: Iljitsch van Beijnum Cc: Erik Nordmark , Multi6 In-Reply-To: "Your message with ID" <9E90FBBC-CA71-11D8-9359-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > If we add some multihoming signaling whereby an attacker, which was on > > the path (e.g., by being on the same WiFi subnet as the victim) for a > > short > > time period, can cause damage by essentially using the state creation > > as a way to preserve it's on-path'ness forever, then folks are > > concerned. > > And justifyably so. But wouldn't it be possible to address this in > other ways? Such as having per-direction or even per-session state > rather than per-address? If you assume that there is an upper timelimit on how long a (TCP) connection can last one could take such an approach. But as far as I know the designers of TCP didn't envision such an upper limit, thus some connections might last forever. > I think if the redirection problem by attackers that are on-path > temporarily is limited to individual unprotected sessions, we are not > materially worse off than today as the same attacker could break the > sessions today also, and redirecting an unprotected session presumably > isn't worse than breaking it as the contents aren't secret. I think there is a difference between - someone breaking into to office looking at the pieces of paper on my desk - someone breaking into my office and installing a device which allows them to look at all future pieces of paper I will place on my desk Thus there is a difference between looking at unprotected communication while being on the path, and looking at unprotected communication long after having left the path. But this might be a case where we can make things be slightly worse than in today's Internet since this communication was unprotected in any case. Erik From owner-multi6@ops.ietf.org Wed Jun 30 16:08:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12019 for ; Wed, 30 Jun 2004 16:08:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BflM9-0005JF-DY for multi6-data@psg.com; Wed, 30 Jun 2004 20:06:57 +0000 Received: from [66.92.66.146] (helo=alva.home) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BflM7-0005HI-EZ for multi6@ops.ietf.org; Wed, 30 Jun 2004 20:06:56 +0000 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1BflLl-0003rs-00; Wed, 30 Jun 2004 16:06:33 -0400 From: Tim Shepard To: "Henderson, Thomas R" cc: "marcelo bagnulo braun" , "Jukka Ylitalo" , "Multi6 List" , "Erik Nordmark" Subject: Re: about Wedgelayer 3.5 / Fat IP approaches In-reply-to: Your message of Wed, 30 Jun 2004 11:02:45 -0700. <6938661A6EDA8A4EA8D1419BCE46F24C04060722@xch-nw-27.nw.nos.boeing.com> Date: Wed, 30 Jun 2004 16:06:33 -0400 Message-Id: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > > CB64 -like split sounds good. Right, there arises some AID > > > ownership problems if it is not bound to the HIT. > > > It would be nice to have a new version of Multi6 HIP draft that > > > describes how HIP could be used with CB64 -like AIDs. > > > > > > > how this would differ from the cb64 draft by Erik? > > > So, assuming that HIP hosts started to use low order bits of the > [...] > details): > - CB64 handshake occurs in parallel with start of data transfer > (actually, after first data packet has been sent), while HIP holds > the first packet waiting for HIP handshake to complete (or > possibly piggybacks it on the HIP exchange).=20 > - CB64 uses flow IDs and locators as keys to find context state > for the session, while HIP uses IPsec SPIs > - CB64 adds new locator for peer upon discovering it as a source > address in a packet (and issuing PK-signed challenge/response),=20 > while HIP explicitly signals the new locator in a signed HIP=20 > exchange. > > Another difference is length of the hash of the key, which may > cause some subtle differences. With 64 bit IDs (or, strictly > speaking, ID tags, since the public keys are the actual > identifiers), we can provide an embedded stack name in the AID,=20 > whereas with HITs, we can only provide a mapping between=20 > (truncated) stack name and AIDs. When we have discussed=20 > shortening HITs to accommodate some structure to aid reverse=20 > lookups, there have been concerns raised that 64 bit IDs might=20 > not be strong enough to withstand server farm attacks in the=20 > future (generating different key that hashes to same ID). =20 > [...] I am concerned about putting hashes in the bottom 64-bits of IPv6 addresses, because that may lead to a future (albiet, probably a few years or decades out) when we discover that some situations are constrained by a shortage of IPv6 address space. For example, someone who only gets a /48 prefix from their provider, and has gazillions of machines to deploy whose stacks and/or applications all expect the bottom 64-bits to be this hash thing, has to do all of their subnetting in a 16-bit field. That 16-bit field is just too small for my taste. I'd worry a lot less if it was 32-bits. So maybe if we can figure out how to ensure that anyone who wants one can get a /40 prefix from each and every ISP that they buy some connectivity from, and can confine the hash thing to the bottom 56 bits of the IPv6 address, then that would laeve 32-bits in between, and it might then be OK. But now 56-bits might not be long enough to get the security we want from the hash? Maybe IPv6 should have been designed with 192-bit addresses so that there would clearly be enough bits to put together all of these sorts of techniques. -Tim Shepard shep@alum.mit.edu