From owner-multi6@ops.ietf.org Sun Aug 1 00:03: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 AAA03977 for ; Sun, 1 Aug 2004 00:03:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Br7WW-000NKn-TC for multi6-data@psg.com; Sun, 01 Aug 2004 04:00:36 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Br7WM-000NJd-5D for multi6@ops.ietf.org; Sun, 01 Aug 2004 04:00:26 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id AAC1748A for ; Sun, 1 Aug 2004 00:00:24 -0400 (EDT) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 01 Aug 2004 00:00:24 -0400 Message-Id: <20040801040024.AAC1748A@cyteen.hactrn.net> 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 Messages | Bytes | Who --------+------+--------+----------+------------------------ 24.39% | 10 | 37.33% | 75388 | pekka.nikander@nomadiclab.com 17.07% | 7 | 12.22% | 24684 | iljitsch@muada.com 14.63% | 6 | 13.03% | 26310 | brc@zurich.ibm.com 9.76% | 4 | 12.75% | 25737 | marcelo@it.uc3m.es 7.32% | 3 | 4.89% | 9874 | kurtis@kurtis.pp.se 4.88% | 2 | 3.64% | 7347 | erik.nordmark@sun.com 4.88% | 2 | 3.03% | 6124 | spencer@mcsr-labs.org 2.44% | 1 | 3.73% | 7538 | lear@cisco.com 2.44% | 1 | 1.96% | 3961 | jordi.palet@consulintel.es 2.44% | 1 | 1.87% | 3776 | jari.arkko@piuha.net 2.44% | 1 | 1.60% | 3226 | john.loughney@nokia.com 2.44% | 1 | 1.41% | 2854 | pekkas@netcore.fi 2.44% | 1 | 1.40% | 2817 | vijayd@iprg.nokia.com 2.44% | 1 | 1.14% | 2297 | sra@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 41 |100.00% | 201933 | 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 Aug 1 11:04: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 LAA05244 for ; Sun, 1 Aug 2004 11:04:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrHrC-000E2M-Tu for multi6-data@psg.com; Sun, 01 Aug 2004 15:02:38 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrHqu-000DyP-2B for multi6@ops.ietf.org; Sun, 01 Aug 2004 15:02:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i71F2IZ31975 for ; Sun, 1 Aug 2004 18:02:18 +0300 Date: Sun, 1 Aug 2004 18:02:18 +0300 (EEST) From: Pekka Savola To: multi6@ops.ietf.org Subject: comments on draft-ietf-multi6-v4-multihoming-01 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 Hi, FWIW, I think section 3 on multihoming motivations is useful. If we skip that, I think a relevant part of the v4 background motivations may get forgotten. And if we can't formulate well enough our past mistakes, ..... (Yes, I think it would take some amount of work to boost the section a bit, but it'd probably still be very useful. On the other hand, some of those clarifications should already be added to section 5 if not in section 3.) semi-editorial -------------- 5. Features of IPv4 Multihoming ==> actually, don't these depend quite a bit on the v4 multihoming mechanism used. Especially it would be worth pointing out that RFC2260/NAT -based mechanisms have a significantly smaller subset of these features. editorial --------- ==> throughout the document, s/enterprise/site/ ? again, and as a result some providers decided to start filtering prefixes it accepted from peers based on prefix length. This broke ==> s/it/they/ 4. Current methods used for IPv4 multihoming ==> lots and lots of typos etc. in this section; I spotted over 5 in 4.2, 4.3 and 4.4. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Sun Aug 1 19:58: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 TAA03202 for ; Sun, 1 Aug 2004 19:58:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrQCM-000F1r-W9 for multi6-data@psg.com; Sun, 01 Aug 2004 23:57:02 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrQBw-000EwN-9r for multi6@ops.ietf.org; Sun, 01 Aug 2004 23:56:36 +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 i71NuYJ6023076; Sun, 1 Aug 2004 16:56:35 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i71NuVJR023692; Mon, 2 Aug 2004 01:56:32 +0200 (MEST) Date: Sun, 1 Aug 2004 11:31:45 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Unique identifiers and privacy To: Christian Huitema Cc: Erik Nordmark , Brian E Carpenter , 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.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 am concerned with the general statement that we should merely "do no > worse than the current state of the art". I am specifically concerned > with the use of long lived unique identifiers. We have already got > significant feedback on such identifiers in a number of products, e.g. > identifiers of CPU chips, identifiers of users of audio-video players, > host identifiers in IPv6, use of social security numbers in data bases, > and the list goes on. Any unique identifier is a privacy time bomb. I was confused by your use of "unique" until I realized it can have two different meanings: - unique as in one host having only one identifier - unique as in "globally unique" i.e. not being assigned to any other host For a privacy attacker to be able to correlate different communication to a single host (which might in turn be used by a single or a few users) the host would need to use only a single identifier and that identifier can't be used by too many other hosts in the Internet. (But global uniqueness probably isn't required since the attacker might very well be able to cope with a handful of hosts using the same identifier.) > Obviously, there are places where unique identifiers are unavoidable. > For example, one cannot receive mail without publishing a mail address > of some kind. But there are many places where identifiers are in fact > not needed. For example, a vast majority of Internet connections involve > resolving the name of a server, obtaining the server address or > "locator", and exchanging a few packets between a single pair of > locators. A cautious design would not mandate use of any identifier in > such circumstances. Agreed. > If we do use identifiers, we should obviously allow systems to create > short-lived identifiers, and to use different identifiers for different > activities. However, we should be very concerned with the default > behavior. In practice, many application developers don't bother with > advanced API and just use whatever is the default behavior of the stack. > A cautious design would be to err on the side of privacy, and to make > sure that by default, an application's traffic will use an identifier > that is both short-lived and specific to that application. The use of > long lived global identifiers should be reserved to those applications > that specifically request them. I think the default is subject to debate, which is most likely a repeat of the debate we had in IPv6 WG whether RFC 3041 addresses should be preferred by default. If we have the default err on the side of privacy the risk is that some applications will fail to communicate (since the identifiers might be too short-lived for the applications need). And as you point out, if we have the default err on the side of identifier stability, the risk is increased privacy exposure due to applications/middleware not using the API to choose the short-lived identifiers. I personally think we do need the applications to get involved, since both defaults are suboptimal. Erik From owner-multi6@ops.ietf.org Sun Aug 1 19:58: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 TAA03220 for ; Sun, 1 Aug 2004 19:58:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrQCm-000F3v-8z for multi6-data@psg.com; Sun, 01 Aug 2004 23:57:28 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrQBx-000EwY-IV for multi6@ops.ietf.org; Sun, 01 Aug 2004 23:56:37 +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 i71NuVil013686; Sun, 1 Aug 2004 17:56:31 -0600 (MDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i71NuRJR023687; Mon, 2 Aug 2004 01:56:28 +0200 (MEST) Date: Sun, 1 Aug 2004 11:20:49 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: how much privacy do we need? (was Re: Advantages and disadvantages of using CB64 type of identifiers To: Christian Huitema Cc: marcelo bagnulo braun , Erik Nordmark , Multi6 List , Iljitsch van Beijnum 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 [Catching up] > > So, i agree with Erik that there are three roles that an app can play: > > - Server > > - Client > > - p2p participant > > We have to be careful when using this terminology. The definition of > server, for example, has two common meanings. For the general public, a > server is some machine that seats in a computer center and provides a > set of services. In many protocol definitions, the server is the party > in the communication that accepts a TCP connection. Obviously, the > privacy requirements are derived from the first definition, not the > second one, and we should make that very clear. I agree it would be confusing. *If* we need to use terms in this space, I'd suggest we use different terms than client and server. Initiator and responder (and both) are the roles the applications play with respect to different ways they communicate so those might be reasonable terms to use. Then the actual privacy requirements are derived from the intent of the user; a single desktop/laptop might have applications that work as initiators (such as web browsing) as well as responders (a VoIP for incoming calls). > The draft states: > > Today when a site is multihomed to multiple ISPs the common setup is > that a single IP address prefix is used with all the ISPs. As a > result it is possible to track that it is the same host that is > communication via all ISPs. > > This is correct, but incomplete. When a *host* is multi-homed to several > ISP, e.g. through a GPRS connection and a wireless hot spot, the host is > provided with different IP addresses on each interface. I know that > multi6 studies "site" multi-homing, but I also know that the various > wedge solutions can potentially be used for host multi-homing scenarios > as well, and I am worried about that. I can add this to the draft. > We may also observe that a common practice in site multi-homing in IPv4 > is to use some form of address translation, effectively hiding the > identity of the specific host within a site. The ability to use middleboxes (NATs, proxies) to hide IP addresses is presumably an option whether multihomed or not. Thus I'll make this as a general comment in the section in the draft. Erik From owner-multi6@ops.ietf.org Mon Aug 2 09:48: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 JAA07332 for ; Mon, 2 Aug 2004 09:48:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brd9E-00012U-NZ for multi6-data@psg.com; Mon, 02 Aug 2004 13:46:40 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brd93-00011K-QC for multi6@ops.ietf.org; Mon, 02 Aug 2004 13:46:30 +0000 Received: from [69.83.213.181] (181.sub-69-83-213.myvzw.com [69.83.213.181]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i72DjvJ08787; Mon, 2 Aug 2004 06:45:58 -0700 (PDT) Message-ID: <410E4591.2080606@isi.edu> Date: Mon, 02 Aug 2004 06:45:53 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Brian E Carpenter , Multi6 Subject: Re: Install DNS mappings based on TLS/IPsec? References: <906B9382-CA0D-11D8-9359-000A95CD987A@muada.com> <40E7C318.8080909@zurich.ibm.com> <4C81F70F-CDA0-11D8-9011-000A95CD987A@muada.com> In-Reply-To: <4C81F70F-CDA0-11D8-9011-000A95CD987A@muada.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig716240C64443D0C098C80220" 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) --------------enig716240C64443D0C098C80220 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 4-jul-04, at 10:43, Brian E Carpenter wrote: > >> Are you suggesting that the multi6 solution should have a strict >> dependency on using TLS or IPSEC? > > > Certainly not. I'm saying two things: > > - if the DNS doesn't work, discover information that would normally be > in the DNS through the TLS or IKE negotiation, and Sorry for the late addition to the thread, but the use of the DNS for forward and reverse lookups is often to provide confirmation of identity. To that end, DNSSEC is useful, by removing the assumption of trust with true trust. The presumption in either case is that if the DNS tree verifies fwd/rev, then things are reasonable. IKE relies either on X.509 keys (a different hierarchy) or preshared secrets. At best, all this does is move the problem (DNSSEC certificate hierarchy -> X.509 certificate hierarchy); at worst, it exposes the endpoint to assuming identity when the pre-shared key could be open (compromised, or deliberate). I.e., it would be necessary (IMO) to limit this to identities exchanged by IKE/TLS based on CAs, not based on preshared keys. That may not be feasible. > - the DNS is often insecure, so let the TLS or IKE derived information > override it to increase security The more independent trust mechanisms there are the less trust that results, IMO. Joe > But if TLS/IPsec aren't used, the information is taken from the DNS. > --------------enig716240C64443D0C098C80220 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 iD8DBQFBDkWWE5f5cImnZrsRAqasAJ9dZ/qQnPfJZNqRec39z7R3oqNBDACeOmFu 1Pg0sVU8iesTbJxPybGEZIc= =menB -----END PGP SIGNATURE----- --------------enig716240C64443D0C098C80220-- From owner-multi6@ops.ietf.org Mon Aug 2 17:47: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 RAA07687 for ; Mon, 2 Aug 2004 17:47:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrkdX-0001pd-TA for multi6-data@psg.com; Mon, 02 Aug 2004 21:46:27 +0000 Received: from [130.129.130.254] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrkdN-0001oh-FG for multi6@ops.ietf.org; Mon, 02 Aug 2004 21:46:17 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 6E3EF50EFF8 for ; Mon, 2 Aug 2004 23:46:17 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <5DE47136-E4CD-11D8-91C5-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=US-ASCII; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Jabber log Date: Mon, 2 Aug 2004 23:46:10 +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,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 The Jabber log of todays session can be found at http://www.xmpp.org/ietf-logs/multi6@ietf.xmpp.org/2004-08-02.html - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQQ62JqarNKXTPFCVEQJxqgCgkHb6UJTdB3a032BmG5WIdMCjFRsAn2aE nWAWKf4RlA8ZfGEUS5D1GsYi =qGGc -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Aug 2 18:08: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 SAA09014 for ; Mon, 2 Aug 2004 18:08:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brkxv-00049U-QH for multi6-data@psg.com; Mon, 02 Aug 2004 22:07:31 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brkxk-00048R-Ra for multi6@ops.ietf.org; Mon, 02 Aug 2004 22:07:21 +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 i72M8MSq054119; Tue, 3 Aug 2004 00:08:23 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <410E4591.2080606@isi.edu> References: <906B9382-CA0D-11D8-9359-000A95CD987A@muada.com> <40E7C318.8080909@zurich.ibm.com> <4C81F70F-CDA0-11D8-9011-000A95CD987A@muada.com> <410E4591.2080606@isi.edu> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4EDB3861-E4D0-11D8-805E-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Install DNS mappings based on TLS/IPsec? Date: Tue, 3 Aug 2004 00:07:13 +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.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 2-aug-04, at 15:45, Joe Touch wrote: > the use of the DNS for forward and reverse lookups is often to provide > confirmation of identity. Yes. > To that end, DNSSEC is useful, Sure, but that's not the point. The point is that requiring the presence of a working DNS is dangerous. Obviously the set of working DNSSEC implementations is smaller than the set of working DNS implementations so adding DNSSEC only makes this part worse. > IKE relies either on X.509 keys (a different hierarchy) or preshared > secrets. At best, all this does is move the problem (DNSSEC > certificate hierarchy -> X.509 certificate hierarchy); This is an improvement as the X.509 hierarchy doesn't have to be traversed in real time (barring caching). > at worst, it exposes the endpoint to assuming identity when the > pre-shared key could be open (compromised, or deliberate). > I.e., it would be necessary (IMO) to limit this to identities > exchanged by IKE/TLS based on CAs, not based on preshared keys. That > may not be feasible. I disagree. The ability to configure trust manually is very useful. Obviously when trust is configured using a preshared key this means only the configured identity must be injected into what the application thinks is the DNS, not any arbitrary value the remote side comes up with. >> - the DNS is often insecure, so let the TLS or IKE derived >> information override it to increase security > The more independent trust mechanisms there are the less trust that > results, IMO. That depends on whether you do "or" or "and". Unfortunately, if you want to optimize for avalability you need to do "or" rather than "and". From owner-multi6@ops.ietf.org Mon Aug 2 19:40: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 TAA14928 for ; Mon, 2 Aug 2004 19:40:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrmOU-000CuR-E2 for multi6-data@psg.com; Mon, 02 Aug 2004 23:39:02 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrmOB-000Cra-Jg for multi6@ops.ietf.org; Mon, 02 Aug 2004 23:38:43 +0000 Received: from [130.129.128.128] (opene-130-129-128-128.ietf60.ietf.org [130.129.128.128]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i72NbgJ16216; Mon, 2 Aug 2004 16:37:42 -0700 (PDT) Message-ID: <410ED04A.70308@isi.edu> Date: Mon, 02 Aug 2004 16:37:46 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 List Subject: Re: Install DNS mappings based on TLS/IPsec? References: <906B9382-CA0D-11D8-9359-000A95CD987A@muada.com> <40E7C318.8080909@zurich.ibm.com> <4C81F70F-CDA0-11D8-9011-000A95CD987A@muada.com> <410E4591.2080606@isi.edu> <4EDB3861-E4D0-11D8-805E-000A95CD987A@muada.com> In-Reply-To: <4EDB3861-E4D0-11D8-805E-000A95CD987A@muada.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2EAF21DBAAB7D4A2FA1CE6EB" 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) --------------enig2EAF21DBAAB7D4A2FA1CE6EB Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 2-aug-04, at 15:45, Joe Touch wrote: > >> the use of the DNS for forward and reverse lookups is often to provide >> confirmation of identity. > > Yes. > >> To that end, DNSSEC is useful, > > Sure, but that's not the point. The point is that requiring the presence > of a working DNS is dangerous. Obviously the set of working DNSSEC > implementations is smaller than the set of working DNS implementations > so adding DNSSEC only makes this part worse. OK. >> IKE relies either on X.509 keys (a different hierarchy) or preshared >> secrets. At best, all this does is move the problem (DNSSEC >> certificate hierarchy -> X.509 certificate hierarchy); > > This is an improvement as the X.509 hierarchy doesn't have to be > traversed in real time (barring caching). How so? If the CA Certs aren't already imported, IKE won't accept them until they're verified. If they are, that's equivalent to DNS caching its keys, isn't it? >> at worst, it exposes the endpoint to assuming identity when the >> pre-shared key could be open (compromised, or deliberate). > >> I.e., it would be necessary (IMO) to limit this to identities >> exchanged by IKE/TLS based on CAs, not based on preshared keys. That >> may not be feasible. > > I disagree. The ability to configure trust manually is very useful. > Obviously when trust is configured using a preshared key this means only > the configured identity must be injected into what the application > thinks is the DNS, not any arbitrary value the remote side comes up with. I don't know how we could control where the identities get used based on the kind of trust that is provided - that's the concern. >>> - the DNS is often insecure, so let the TLS or IKE derived >>> information override it to increase security > >> The more independent trust mechanisms there are the less trust that >> results, IMO. > > That depends on whether you do "or" or "and". Unfortunately, if you want > to optimize for avalability you need to do "or" rather than "and". "or" usually decreases trust, in the sense that you can only assume the lowest common denomenator. Joe --------------enig2EAF21DBAAB7D4A2FA1CE6EB 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 iD8DBQFBDtBKE5f5cImnZrsRAi48AJ9VIYeZ4oEFel5L90tANe2x/cR4OQCgqgaj viUzmDv1tSr3fD5Oc/q9+ec= =NOnf -----END PGP SIGNATURE----- --------------enig2EAF21DBAAB7D4A2FA1CE6EB-- From owner-multi6@ops.ietf.org Mon Aug 2 21:56: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 VAA21741 for ; Mon, 2 Aug 2004 21:56:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BroWZ-0002lB-Bg for multi6-data@psg.com; Tue, 03 Aug 2004 01:55:31 +0000 Received: from [131.160.193.2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BroWN-0002jt-V9 for multi6@ops.ietf.org; Tue, 03 Aug 2004 01:55:20 +0000 Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 267FF212CB7; Tue, 3 Aug 2004 04:55:19 +0300 (EEST) Date: Tue, 3 Aug 2004 04:55:19 +0300 (EEST) From: Jukka Ylitalo To: Christian Huitema , Erik Nordmark Cc: Brian E Carpenter , Multi6 List Subject: Re: Unique identifiers and privacy In-Reply-To: Message-ID: References: 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 > I am concerned with the general statement that we should merely "do no > worse than the current state of the art". I am specifically concerned > with the use of long lived unique identifiers. We have already got > significant feedback on such identifiers in a number of products, e.g. > identifiers of CPU chips, identifiers of users of audio-video players, > host identifiers in IPv6, use of social security numbers in data bases, > and the list goes on. Any unique identifier is a privacy time bomb. Hi Christian, We have presented a HIP variant (see below) in our latest Cambridge Security Workshop paper that offers identity privacy protection for long lived unique identifiers, e.g., for HITs. I believe that it is possible to apply the same mechanism with other wedge layer 3.5 identifiers. "Jukka Ylitalo, and Pekka Nikander, "BLIND: A Complete Identity Protection Framework for End-points", to appear in Proceedings of the Twelfth International Workshop on Security Protocols, (Cambridge'04), Sidney Sussex College, Cambridge, England, April 26-28, 2004." http://www.hut.fi/~jylitalo/publications/Cam04-Ylitalo-Nikander.pdf br, Jukka From owner-multi6@ops.ietf.org Mon Aug 2 23:34: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 XAA26301 for ; Mon, 2 Aug 2004 23:34:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brq3X-000C8x-Rl for multi6-data@psg.com; Tue, 03 Aug 2004 03:33:39 +0000 Received: from [207.69.200.157] (helo=tisch.mail.mindspring.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brq3N-000C82-2x for multi6@ops.ietf.org; Tue, 03 Aug 2004 03:33:29 +0000 Received: from 1cust146.tnt36.dfw9.da.uu.net ([67.234.81.146] helo=ix.netcom.com) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1Brq3G-000554-00; Mon, 02 Aug 2004 23:33:23 -0400 Message-ID: <410F20AA.EC7731FC@ix.netcom.com> Date: Mon, 02 Aug 2004 22:20:46 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Joe Touch CC: Iljitsch van Beijnum , Brian E Carpenter , Multi6 Subject: Re: Install DNS mappings based on TLS/IPsec? References: <906B9382-CA0D-11D8-9359-000A95CD987A@muada.com> <40E7C318.8080909@zurich.ibm.com> <4C81F70F-CDA0-11D8-9011-000A95CD987A@muada.com> <410E4591.2080606@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=-3.8 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 Joe and all, It would seem that following what is more and and more recognized in the commercial world that a need to do better with Bind and the latest version being more broadly implemented would be more helpful. See: 0. http://www.defcon.org/html/defcon-12/dc-12-index.html 1. http://www.defcon.org/html/defcon-12/dc-12-speakers.html#kaminsky 2. http://news.com.com/2100-1002_3-5291874.html?tag=nefd.top Joe Touch wrote: > Iljitsch van Beijnum wrote: > > > On 4-jul-04, at 10:43, Brian E Carpenter wrote: > > > >> Are you suggesting that the multi6 solution should have a strict > >> dependency on using TLS or IPSEC? > > > > > > Certainly not. I'm saying two things: > > > > - if the DNS doesn't work, discover information that would normally be > > in the DNS through the TLS or IKE negotiation, and > > Sorry for the late addition to the thread, but the use of the DNS for > forward and reverse lookups is often to provide confirmation of identity. > > To that end, DNSSEC is useful, by removing the assumption of trust with > true trust. The presumption in either case is that if the DNS tree > verifies fwd/rev, then things are reasonable. > > IKE relies either on X.509 keys (a different hierarchy) or preshared > secrets. At best, all this does is move the problem (DNSSEC certificate > hierarchy -> X.509 certificate hierarchy); at worst, it exposes the > endpoint to assuming identity when the pre-shared key could be open > (compromised, or deliberate). > > I.e., it would be necessary (IMO) to limit this to identities exchanged > by IKE/TLS based on CAs, not based on preshared keys. That may not be > feasible. > > > - the DNS is often insecure, so let the TLS or IKE derived information > > override it to increase security > > The more independent trust mechanisms there are the less trust that > results, IMO. > > Joe > > > But if TLS/IPsec aren't used, the information is taken from the DNS. > > > > ------------------------------------------------------------------------ > > 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 Mon Aug 2 23:42: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 XAA26826 for ; Mon, 2 Aug 2004 23:42:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrqBJ-000CuG-0I for multi6-data@psg.com; Tue, 03 Aug 2004 03:41:41 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrqB8-000CtK-6M for multi6@ops.ietf.org; Tue, 03 Aug 2004 03:41:30 +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 i733fQ0R007047; Mon, 2 Aug 2004 20:41:27 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i733fMJR005491; Tue, 3 Aug 2004 05:41:23 +0200 (MEST) Date: Mon, 2 Aug 2004 20:41:48 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Comments on threats and things-to-think about To: multi6@ops.ietf.org Cc: erik.nordmark@sun.com, leifj@it.su.se In-Reply-To: "Your message with ID" <410E98A5.1080009@it.su.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=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk This never made it to the multi6 list AFAIK. Erik >----------------Begin Forwarded Message----------------< Date: Mon, 02 Aug 2004 21:40:21 +0200 From: "Leif Johansson" Subject: Kommentarerna jag skickade till Kurtis... To: erik.nordmark@sun.com > draft-nordmark-multi6-threats-02.txt "The third class of applications..." Applications that rely on reverse lookups even beeing available are fundamentally broken and have been for some time (since the arrival of low-cost SOHO broadband in fact). IPv6 multihoming imho should treat this class of applications the same way that the second class. "Finally, the fifth class..." The availability of ipsec (and similar solutions) together with channel bindings allow protocols which in themselves are vulnerable to MITM-attacks to operate with a high level of confidentiality in the security of the identification of the peer. A typical example is the Remote Desktop Protocol (RDP) which when used with oportunistic ipsec works well if channel bindings are available. Channel bindings provide a link between the ip-layer identification and the application protocol identification. This is an important aspect of security in application protocols which must be preserved by a multi6 solution. Apart from these comments my first read of this draft (especially some of the sections on identification spoofing attacks) read like an account of how to get into trouble with ssh tunneling - these things happens today all the time. This is not to say that there are solutions in this space because there isn't The lack of efficient key-management is the root of all evil to paraphrase Knuth. > draft-lear-multi6-things-to-think-about-03.txt 2.3.6 - Very important. Latency for global voice applications is tethering on the possible as it is. 2.4 - Explain how your solution helps/impacts/affects renumbering especially for large sites. 2.4.11.1 - 2.4.11 is really a trick question. You are toast if you need to touch gethostbyname or getaddrinfo. 2.4.19.1 - Provide a detailed walk-through of SIP+RTSP when one or several of the peers are multihomed. How does your analysis change when encrypted rtsp is used or when SIP with S/MIME e2e signalling is used? 2.4.19.2 - Show how protocols with embedded encrypted ip-adresses (eg RX used in AFS) are affected. NB that RX is built on top of UDP. This is essentially the same as 2.4.19.1 but I like to plug AFS :-) >----------------End Forwarded Message----------------< From owner-multi6@ops.ietf.org Tue Aug 3 00:34: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 AAA00197 for ; Tue, 3 Aug 2004 00:34:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrqzN-000IRl-UC for multi6-data@psg.com; Tue, 03 Aug 2004 04:33:25 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brqz5-000IP4-8m for multi6@ops.ietf.org; Tue, 03 Aug 2004 04:33:07 +0000 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Mon, 2 Aug 2004 21:33:05 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Aug 2004 21:33:12 -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); Mon, 2 Aug 2004 21:33:05 -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); Mon, 2 Aug 2004 21:32:04 -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: Unique identifiers and privacy Date: Mon, 2 Aug 2004 21:33:05 -0700 Message-ID: Thread-Topic: Unique identifiers and privacy thread-index: AcR4/P81jDQv6YSdQvK/R84OgOPheAAFBn2A From: "Christian Huitema" To: "Jukka Ylitalo" , "Erik Nordmark" Cc: "Brian E Carpenter" , "Multi6 List" X-OriginalArrivalTime: 03 Aug 2004 04:32:04.0480 (UTC) FILETIME=[D3E83800:01C47912] 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 > We have presented a HIP variant (see below) in our latest Cambridge > Security Workshop paper that offers identity privacy protection for > long lived unique identifiers, e.g., for HITs. I believe that it is > possible to apply the same mechanism with other wedge layer 3.5 > identifiers. Well, the paper explains that it would be inconvenient for M to refer to James Bond by location, e.g. "10 Market Street" and later "101 Main Street". You use that to make the classic case for location independent identifiers, but this case disregard the fact that while James Bond may want to be known to M, he probably does not want to be immediately recognized as James Bond by Goldfinger and Dr. No. In fact, when dealing with these characters, being known by the current location may be vastly preferable. You do obtain some privacy by conducting a Diffie-Hellman exchange before actually exchanging the identity. This will meet one of the privacy requirements, by making the identity opaque to the third parties in the path. However, you do not solve all the issues related to permanent identities, i.e. that Mr. Bond wants to present uncorrelated identities to M and to Goldfinger. In the latter case, we probably want something much more light weight than a full cryptographic exchange -- some random number would be fine, along the lines of the COT/COTI exchange in MIP6. By the way, I did not actually analyze the way you suggest to use Diffie-Hellman and public keys, but I have the impression that your mechanism is very similar to IKE. This begs an obvious question. Cryptographic protocols are notoriously hard to get right. Instead of inventing a new one, we should probably work with the IPSEC working group and either adapt IKE or make sure that the planned revision of IKE also meets the needs of Multi6.=20 -- Christian Huitema From owner-multi6@ops.ietf.org Tue Aug 3 12:10: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 MAA17981 for ; Tue, 3 Aug 2004 12:10:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs1pz-000AJ9-Gk for multi6-data@psg.com; Tue, 03 Aug 2004 16:08:27 +0000 Received: from [131.160.193.2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs1pg-000AGd-2m for multi6@ops.ietf.org; Tue, 03 Aug 2004 16:08:08 +0000 Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 0A70E212C8E; Tue, 3 Aug 2004 19:08:07 +0300 (EEST) Date: Tue, 3 Aug 2004 19:08:07 +0300 (EEST) From: Jukka Ylitalo To: Christian Huitema Cc: Erik Nordmark , Brian E Carpenter , Multi6 List Subject: RE: Unique identifiers and privacy In-Reply-To: Message-ID: References: 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=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, The paper was an answer to part of your worries about the identifier privacy problems. I'll continue the discussion off-list, because the paper is a bit out of Multi6 scope, and most people haven't read it. Thanks, Jukka > Well, the paper explains that it would be inconvenient for M to refer to > James Bond by location, e.g. "10 Market Street" and later "101 Main > Street". You use that to make the classic case for location independent > identifiers, but this case disregard the fact that while James Bond may > want to be known to M, he probably does not want to be immediately > recognized as James Bond by Goldfinger and Dr. No. In fact, when dealing > with these characters, being known by the current location may be vastly > preferable. > > You do obtain some privacy by conducting a Diffie-Hellman exchange > before actually exchanging the identity. This will meet one of the > privacy requirements, by making the identity opaque to the third parties > in the path. However, you do not solve all the issues related to > permanent identities, i.e. that Mr. Bond wants to present uncorrelated > identities to M and to Goldfinger. In the latter case, we probably want > something much more light weight than a full cryptographic exchange -- > some random number would be fine, along the lines of the COT/COTI > exchange in MIP6. > > By the way, I did not actually analyze the way you suggest to use > Diffie-Hellman and public keys, but I have the impression that your > mechanism is very similar to IKE. This begs an obvious question. > Cryptographic protocols are notoriously hard to get right. Instead of > inventing a new one, we should probably work with the IPSEC working > group and either adapt IKE or make sure that the planned revision of IKE > also meets the needs of Multi6. > > -- Christian Huitema > > From owner-multi6@ops.ietf.org Thu Aug 5 13:36: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 NAA01937 for ; Thu, 5 Aug 2004 13:36:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bsm8x-0002dm-OJ for multi6-data@psg.com; Thu, 05 Aug 2004 17:35:07 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bsm8m-0002ax-0A for multi6@ops.ietf.org; Thu, 05 Aug 2004 17:34:56 +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 i75HYsGm111856 for ; Thu, 5 Aug 2004 17:34:54 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 i75HYsh6207014 for ; Thu, 5 Aug 2004 19:34:54 +0200 Received: from zurich.ibm.com (sig-9-145-169-161.de.ibm.com [9.145.169.161]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA40798 for ; Thu, 5 Aug 2004 19:34:53 +0200 Message-ID: <41126FBB.90407@zurich.ibm.com> Date: Thu, 05 Aug 2004 19:34:51 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: TASL 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 Co-chair hat is OFF I know that the WG is not looking for yet more solutions proposals, but the idea below (which seems very obvious) came to me when thinking about the DNS dependency in NOID. I'm sending this message to get the idea on the record, but I don't intend to write a complete draft... this is simply something that the wedge layer design team may want to consider. Oh, and if this idea has already been proposed in the past, please say so. Transport Assisted Shim Layer (TASL) In TASL, a pair of MUltihoming SHims (MUSHes) communicate independently of the IP flow that is to benefit from multihoming, using TLS, in order to establish shared MUltihoming STate (MUST). The TASL exchange itself isn't multihomed, to avoid a recursion issue. [But if it was in fact established over SCTP instead of TCP, that issue would go away.] At the highest level it looks like this. ULID = Upper Level Identifier (a.k.a. AID), but it's actually an IPv6 address that serves as the initial locator for a host in a multihomed session. _________ ____ ____ _________ | | | | | | | | | MUSH1 | | | | | | MUSH2 | | <-|---|-----TLS------|---|-> | | | | | | | | | | _____ | | | | | | _____ | ULP | | | | | | | | | | | | ULP send(ULID2)-->|-|MUST1|-|-->|-IP-|....|-IP-|-->|-|MUST2|-|--->receive | |_____| | | | | | | |_____| | |_________| |____| |____| |_________| The ULP in host 1 sends a first packet to the ULID of host 2 (ULID2), sourced from its own ULID (ULID1). The MUSH in host 1 intercepts this packet, creates empty MUST for it, and sends the first packet on its way to locator ULID1. MUSH1 asynchronously opens a TLS session to a well-known port at host 2 on locator ULID2. It then uses NOID- or MAST-like protocol elements on that session to exchange locator lists with MUSH2. As long as the session stays open, updates can be conveyed. The locator lists and any other state is saved in MUST1 and MUST2. (Presumably, the contents of MUST1 and MUST2 will be equivalent.) Presumably MUSH1 binds to an ephemeral port, and contacts MUSH2 on a well-known port at ULID2. Potentially, the same inter-MUSH TLS session is shared among all ULPs that use the same ULID pair. There is a risk here of (up to) doubling the number of ports in use, and that can be a scaling disadvantage of this solution. Since the protocol exchange is protected by TLS, we are certain that no 3rd party has injected bogus locators or been able to observe the locator exchange. Thus, whichever host initially responded to locator ULID2 is the only one able to send and receive news of alternative locators, and only to the host that initially used locator ULID1. This seems to cover a lot of the multihoming threats. If host 2 doesn't have a MUSH, it will not respond to the TLS session, so host 1 will never establish MUST, and MUSH1 will be transparent to the packet flow. The ULP session will proceed with its original locators until a multihoming event occurs, at which time source and/or destination locators will change. The incoming packets at host 2 will at all times be matched to the state in MUST2; likely the 3-tuple {srce, dest, flow_label} will be used, and that will define the granularity of multihoming between host 1 and host 2. If the source changes from ULID1, and/or the destination changes from ULID2, as long as the new locators are saved in MUST2, the packet will be accepted and the original {ULID1, ULID2} will be restored just as in NOID. Instead of the 3-tuple of {src, dst, flow_label}, a 2-tuple of {src, dst} could be used. That would share the MUST among all sessions using the same initial pair of ULIDs. (As long as most traffic has no flow label, that will happen anyway.) Of course an attacker can inject spoofed packets using any valid locator pair at any time. But that's always been true. TASL means that no third party can learn the locators in use. If the TLS session (which isn't multihomed) goes down, further updates to the MASTs become impossible --- so we should ensure that the initial exchange involves an unguessable nonce, which will be kept secret by TLS. Then a new TLS session can be created, between a new pair of locators, and connected to the existing MASTs by use of the nonce. The mechanism for choosing new locators, either when a multihoming event occurs, or when the TLS session goes down, is not defined here (but needs to be defined somewhere). Note that this is all a one-way solution as far as the ULP is concerned. If ULP packets come back from host 2 to host 1, the whole thing is repeated independently in the reverse direction. However, there is no reason that an implementation can't optimize by noting that a TLS session and MUST state already exists in the reverse direction, and short-circuiting the state exchange as far as possible - it can probably be completely eliminated if the flow label is zero. Brian Carpenter with help from Roy Brabson From owner-multi6@ops.ietf.org Thu Aug 5 19:06: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 TAA24547 for ; Thu, 5 Aug 2004 19:06:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsrHa-000JFC-5E for multi6-data@psg.com; Thu, 05 Aug 2004 23:04:22 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsrHP-000JEF-IH for multi6@ops.ietf.org; Thu, 05 Aug 2004 23:04:11 +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 i75N4AJ6005522; Thu, 5 Aug 2004 16:04:10 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i75N46JR024689; Fri, 6 Aug 2004 01:04:08 +0200 (MEST) Date: Thu, 5 Aug 2004 16:04:32 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: TASL To: Brian E Carpenter Cc: Multi6 In-Reply-To: "Your message with ID" <41126FBB.90407@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 > Since the protocol exchange is protected by TLS, we are certain > that no 3rd party has injected bogus locators or been able to > observe the locator exchange. Thus, whichever host initially > responded to locator ULID2 is the only one able to send and receive > news of alternative locators, and only to the host that initially > used locator ULID1. This seems to cover a lot of the multihoming > threats. This assumes that the responder has a certificate? What is the binding between that certificate and the identity of the responder? Based on the FQDN matching, or based on having IP address(es) in the certificate? Assuming we worry about pre-meditated attacks (aka time-shifting attacks) we do need a reasonably strong binding between the cert and the responder. > Note that this is all a one-way solution as far as the ULP is concerned. > If ULP packets come back from host 2 to host 1, the whole thing is > repeated independently in the reverse direction. Does this mean that a separate tls session is established in the reverse direction? Would the initiator of the communication need a TLS certificate? Erik From owner-multi6@ops.ietf.org Thu Aug 5 23:11: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 XAA07546 for ; Thu, 5 Aug 2004 23:11:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bsv6W-000M7n-0c for multi6-data@psg.com; Fri, 06 Aug 2004 03:09:12 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bsv6K-000M6j-RX for multi6@ops.ietf.org; Fri, 06 Aug 2004 03:09:01 +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 i7638w69126476; Fri, 6 Aug 2004 03:08: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 i7638vh6224020; Fri, 6 Aug 2004 05:08:57 +0200 Received: from zurich.ibm.com (sig-9-145-173-126.de.ibm.com [9.145.173.126]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id FAA97352; Fri, 6 Aug 2004 05:08:50 +0200 Message-ID: <4112F640.8020405@zurich.ibm.com> Date: Fri, 06 Aug 2004 05:08:48 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Erik Nordmark CC: Multi6 Subject: Re: TASL 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: >>Since the protocol exchange is protected by TLS, we are certain >>that no 3rd party has injected bogus locators or been able to >>observe the locator exchange. Thus, whichever host initially >>responded to locator ULID2 is the only one able to send and receive >>news of alternative locators, and only to the host that initially >>used locator ULID1. This seems to cover a lot of the multihoming >>threats. > > > This assumes that the responder has a certificate? > What is the binding between that certificate and the identity of the > responder? Based on the FQDN matching, or based on having IP address(es) > in the certificate? Personally I'd rather avoid any DNS dependence so maybe it has to be address based... but I'm too tired to think very clearly tonight... > Assuming we worry about pre-meditated attacks (aka time-shifting attacks) > we do need a reasonably strong binding between the cert and the responder. Yes > > >>Note that this is all a one-way solution as far as the ULP is concerned. >>If ULP packets come back from host 2 to host 1, the whole thing is >>repeated independently in the reverse direction. > > > Does this mean that a separate tls session is established in the reverse > direction? In the general case I think so, but it might be possible to optimize it out in many cases. > Would the initiator of the communication need a TLS certificate? That seems likely to be necessary. The idea is half baked of course - I just wanted it on the table in case it has any merit. Brian From owner-multi6@ops.ietf.org Sat Aug 7 20:00: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 UAA01353 for ; Sat, 7 Aug 2004 20:00:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Btb4P-0007vx-RZ for multi6-data@psg.com; Sat, 07 Aug 2004 23:57:49 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Btb4F-0007u5-8t for multi6@ops.ietf.org; Sat, 07 Aug 2004 23:57:39 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i77NvbN22989; Sat, 7 Aug 2004 16:57:37 -0700 Date: Sat, 7 Aug 2004 16:57:32 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1421753838.20040807165732@brandenburg.com> To: Brian E Carpenter CC: Multi6 Subject: Re: TASL In-Reply-To: <41126FBB.90407@zurich.ibm.com> References: <41126FBB.90407@zurich.ibm.com> MIME-Version: 1.0 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.6 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, BEC> In TASL, a pair of MUltihoming SHims (MUSHes) communicate independently of BEC> the IP flow that is to benefit from multihoming, using TLS, in order to I apologize for seeming to be reading-impaired, but I am not seeing what significant differences there are between TASL and MAST. Please elighten me. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-multi6@ops.ietf.org Sun Aug 8 00:02: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 AAA10979 for ; Sun, 8 Aug 2004 00:02:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BterI-000AZs-41 for multi6-data@psg.com; Sun, 08 Aug 2004 04:00:32 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bter7-000AYj-C3 for multi6@ops.ietf.org; Sun, 08 Aug 2004 04:00:21 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 8E162656 for ; Sun, 8 Aug 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, 08 Aug 2004 00:00:20 -0400 Message-Id: <20040808040020.8E162656@cyteen.hactrn.net> 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 Messages | Bytes | Who --------+------+--------+----------+------------------------ 25.00% | 4 | 27.02% | 16298 | erik.nordmark@sun.com 12.50% | 2 | 18.09% | 10910 | brc@zurich.ibm.com 12.50% | 2 | 15.46% | 9325 | touch@isi.edu 12.50% | 2 | 10.85% | 6541 | jukka.ylitalo@nomadiclab.com 6.25% | 1 | 7.22% | 4354 | huitema@windows.microsoft.com 6.25% | 1 | 5.70% | 3438 | iljitsch@muada.com 6.25% | 1 | 4.50% | 2717 | pekkas@netcore.fi 6.25% | 1 | 4.50% | 2714 | sra@hactrn.net 6.25% | 1 | 3.55% | 2144 | dhc@dcrocker.net 6.25% | 1 | 3.10% | 1870 | kurtis@kurtis.pp.se --------+------+--------+----------+------------------------ 100.00% | 16 |100.00% | 60311 | 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 Mon Aug 9 05:49: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 FAA16100 for ; Mon, 9 Aug 2004 05:49:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bu6jK-00033l-D5 for multi6-data@psg.com; Mon, 09 Aug 2004 09:46:10 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bu6il-0002zt-DJ for multi6@ops.ietf.org; Mon, 09 Aug 2004 09:45:35 +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 i799jK69098810; Mon, 9 Aug 2004 09:45:21 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 i799jKsS218496; Mon, 9 Aug 2004 11:45:20 +0200 Received: from zurich.ibm.com (sig-9-145-242-81.de.ibm.com [9.145.242.81]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA89292; Mon, 9 Aug 2004 11:45:19 +0200 Message-ID: <411747B0.10300@zurich.ibm.com> Date: Mon, 09 Aug 2004 11:45:20 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Dave Crocker CC: Multi6 Subject: Re: TASL References: <41126FBB.90407@zurich.ibm.com> <213168238.20040807165710@brandenburg.com> In-Reply-To: <213168238.20040807165710@brandenburg.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 Dave Crocker wrote: > Brian, > > BEC> In TASL, a pair of MUltihoming SHims (MUSHes) communicate independently of > BEC> the IP flow that is to benefit from multihoming, using TLS, in order to > > I apologize for seeming to be reading-impaired, but I am not seeing > what significant differences there are between TASL and MAST. Cuter acronym? :-) Seriously, there is obviously a very close relationship (the actual protocol exchanges would be like those in MAST and NOID, so I didn't spell them out). But when I re-read MAST I don't see it clearly stated that a separate, reliable, and secure transport connection is used to carry the exchanges - that is suggested as an option at the end of the MAST security considerations, but it is basic to TASL. And I don't see any need to use XMPP as you suggest in MAST. So I'd argue it's a simpler approach, but clearly closely related. Brian From owner-multi6@ops.ietf.org Mon Aug 9 05:58: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 FAA16542 for ; Mon, 9 Aug 2004 05:58:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bu6u1-0004Mq-8l for multi6-data@psg.com; Mon, 09 Aug 2004 09:57:13 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bu6ti-0004Km-3h for multi6@ops.ietf.org; Mon, 09 Aug 2004 09:56:54 +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 i799urGm121242; Mon, 9 Aug 2004 09:56:53 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 i799uqsS213594; Mon, 9 Aug 2004 11:56:52 +0200 Received: from zurich.ibm.com (sig-9-145-242-81.de.ibm.com [9.145.242.81]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA70532; Mon, 9 Aug 2004 11:56:51 +0200 Message-ID: <41174A62.90606@zurich.ibm.com> Date: Mon, 09 Aug 2004 11:56:50 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 CC: Erik Nordmark Subject: multi6 wedge layer design team 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 As mentioned in last week's meeting, the co-chairs have asked Erik Nordmark to convene a new multi6 design team to refine the "wedge layer" analysis. Initial membership: Erik Nordmark (convenor), Jari Arkko, Marcelo Bagnulo Braun, Iljitsch van Beijnum, Geoff Huston and Yukka Ylitalo. The team has to be kept small for efficiency, but Erik may decide to add one or two more volunteers. We hope for a draft ready for discussion during the November IETF. Here's the "mission statement": Refine wedge layer/ layer 3.5 analysis to reach an agreed approach (or very small number of approaches) and a list of functions and components needed. The goal is to get to a much smaller set of proposals and/or a unified proposal and identify any problems with the unified direction. It is OK to document directions that can be taken to solve it but we cannot go into protocol specifics within the current WG charter. Brian + Kurtis multi6 cochairs From owner-multi6@ops.ietf.org Mon Aug 9 07:31: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 HAA21534 for ; Mon, 9 Aug 2004 07:31:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bu8K3-000E5J-Vx for multi6-data@psg.com; Mon, 09 Aug 2004 11:28:11 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bu8JK-000E0h-Q4 for multi6@ops.ietf.org; Mon, 09 Aug 2004 11:27: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 i79BROGm103682 for ; Mon, 9 Aug 2004 11:27:24 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 i79BRNsS197190 for ; Mon, 9 Aug 2004 13:27:24 +0200 Received: from zurich.ibm.com (sig-9-145-242-81.de.ibm.com [9.145.242.81]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA68372 for ; Mon, 9 Aug 2004 13:27:22 +0200 Message-ID: <41175F9B.5030604@zurich.ibm.com> Date: Mon, 09 Aug 2004 13:27:23 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Draft multi6 minutes Content-Type: multipart/mixed; boundary="------------070006030406080707020606" 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. --------------070006030406080707020606 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Comments this week please, after which the minutes will be submitted. Brian --------------070006030406080707020606 Content-Type: text/plain; name="multi6-ietf60-minutes.txt" Content-Disposition: inline; filename="multi6-ietf60-minutes.txt" Content-Transfer-Encoding: 8bit Multi6 WG meeting minutes (Tim Chown, 2nd August 2004, edited by co-chairs) Both co-chairs present: Brian Carpenter Kurt Lindqvist Meeting opened 9:05 am, 2nd August Brian reminded attendees of the terms and conditions of IETF meetings and contributions as stated on the yellow sheet given to delegates in the IETF registration pack. There are three parts for this meeting on the agenda. First, there are four drafts to finalise, so we can WGLC and not have them in the next meeting: draft-ietf-multi6-v4-multihoming-01 draft-ietf-multi6-things-to-think-about-00 draft-ietf-multi6-multihoming-threats-00 draft-ietf-multi6-architecture-00 Then a scenarios document: draft-palet-multi6-scenarios-00 And finally a further discussion of next steps, including the Wedgelayer 3.5 / Fat IP approaches and required components. The three-part agenda was accepted, with no changes suggested. ** draft-ietf-multi6-v4-multihoming-01 (Kurtis Lindqvist) Kurtis stated that the list comments were all taken on board. Only major discussion was Chapter 3 on motivations for multihoming, so it had been suggested by Brian Carpenter and Kurtis, on the mailinglist, to take this out and leave it for Jordi's document. Only Pekka have objected to this at this time. Pekka: Mechanisms are different in v4 and v6, so we should remember the scenarios we need to fix in this document. It is not a trivial rewording. Issues such as traffic engineering should be expanded. Maybe half a page is needed. Kurtis: I have no strong view. Pekka: Not all v4 motivations may be supported by a v6 solution. Eric Fleischman: RFC3582 in sec 3.1 has a list of these goals, and the draft list is just a subset. There are 7 reasons in the RFC and 4 in the draft. Kurtis: Maybe we should just refer back. Geoff Huston: There is also the analysis at the end of the architecture draft that could be merged in. Brian: I don't think that's probably the right thing to do. Kurtis: The documents should be consistent. Brian: If things are missing, send text (aimed at Pekka). To avoid endless debate, Kurtis should try to refer draft text back to the RFC, and make the motivation section leaner and more precise. The room agreed that the changes to the document were representative of the list comments. ** draft-ietf-multi6-things-to-think-about-00 (Eliot Lear) Some text based on Geoff's texts, the goal in the new version was to make the questions a bit clearer, and to add applications considerations, e.g. for backwards compatibility, e.g. what happens to hostbyname. There is a danger of misinterpretation if these functions are overloaded, e.g. if log analyser converting IP addresses back to names. Happy to get the document to an Informational RFC, but main goal is to list the problems people should think about. Brian: chairs not sure whether to keep as living document or publish it sooner. Eliot: don't waste time making this perfect, just use it for solutions documents. Tim Chown: these issues should be preserved for future reference Brian: question is just when. ** draft-ietf-multi6-multihoming-threats-00 (Eric Nordmark) Most changes in this version are editorial edits. The biggest addition was discussing the state of privacy in the Internet today, so we can talk about "do no harm" additions in the context of multihoming. Also some more background info for multihoming newcomers. The appendix has been left in place because there is nowhere else to put it. Christian Huitema made specific privacy comments; multihomed hosts have different IP addresses per ISP (making correlation harder), also that v4 middleboxes/NATs today make correlation for snoopers harder. These comments are added now. Christian: We should not just say "do no harm", i.e. not just say "be no worse", rather we should actively try to do better. For example any use of unique identifiers have a privacy risk. Goal is we should do better. Eliot: I disagree. Principal goal is scalable multihoming solution - adding privacy concerns degrades the situation. Brian: I detect Christian is saying "raise the bar". That change is one we should be clear about if we want to do that. Christian: My company is often criticised. There are solutions for multihoming that can make security or privacy harder. We have to be clear about the tradeoff between functionality and privacy. As with the MAC address, our industry has not been cautious. Geoff: Bits of my identity need to be available to do multihoming. If we go locator independent, you are exposing info about bindings that was not previously exposed. The fundamental question is whether we're doing a locator-identifier split. Is there a persistent long-term identify, published, or a per-session method? These have different issues. We already had the debate in the bottom 64 bits for IPv6. Erik: You don't have to expose the same identity to everyone, the single identity is the more dangerous. Geoff: You can't always bind by context, so it becomes longer term. Erik: You still need to make referrals work. Geoff: Not sure. Christian: Making a session live over a change of IP address has less implications. You can engineer your solution to make your identifier visible to your session peer and/or third parties. We should be more explicit. Erik: We should note the peer and 3rd party text in the document. We should make stronger statements about unique identifiers and their concerns. Eric Fleishman?: We should have a solution that hits many layers. Christian's idea of embedding MAC addresses is bad only in some people's eyes. We can't say what is good or bad clearly, because it may depend on the solution. Christian: I would like the considerations there because they are taken as input for the solution designers, hence privacy is important in this document, even if that means the solution is harder to build. Erik: I'll add those comments in the next update Brian: We need WGLC on this very soon. ** draft-ietf-multi6-architecture-00 (Geoff Huston) Has been revised by WG list comments and from the interim meeting, and is now a WG document. Geoff thinks it needs more review and revision, so we can go to Informational RFC. The changelog shows the WG input, e.g. session initialisation when the state is not as you might expect, and to consider traffic engineering across multiple paths. Also some text on endpoint identifier structure - at what point to do know you're dealing with a locator, or an indentity without a locator context. Also disambiguating in the case of load-sharing (i.e. the machine may not be multihomed, the service may be multi-hosted). New text is added on triggering locator change, via ICMP triggers. Also notes on whether identity is per session, or per endpoint independent of session. A new section on functional decomposition of multihoming approaches has been added, due to WG chair input. There is an open issue for which help is needed, wrt MIPv6. There was a comment that there is a "back to base" problem. In multihoming, a fixed, home locator may not be there. So there needs to be text as to why MIPv6 is special in the multihoming space. The appendix on "various approaches" should be split out, to get the main document through quicker. We should document the architecture issues of identifier-locator split, and on the capability negotiation initial handshake, and on describing the various identify types and their potential for coexistence. For example, the application may use identifiers or locators; the capability and semantics need to be clearly understood. Brian: We should look at each of these issues. We need text from someone, e.g. for multihoming and MIPv6 for the first issue. Eliot: In order to initiate contact you need to be able to start by going via the home address. Geoff: That, and also there are timers when you go into care-ofs that you check back with the home address. This may be inappropriate to multihoming. We need text on this. Eliot: Question is why are those timers there and whether or not if we did something else for multi6 we'd end up in the same position. Marcelo volunteered to provide text. Brian: The appendix early analysis text (by Margaret Wasserman) could be split out - it's not architecture per se. Margaret: I am happy to split it out. Is that valuable? Brian: We did some analysis in the interim meeting. This might make you rethink the way the analysis is organised. Margaret: We should structure based on the interim meeting discussion. It needs a lot of updating if it should be kept. Originally it was a text to get people up to speed. maybe it's served its purpose. Brian: We'd need a co-author... Margaret: No, we need an author! Brian: OK, we'll spin this appendix off. It needs an author though. Christian: I volunteer. The WG hum passed the proposal clearly. David Kessens (AD) agreed. Brian (chair hat off): The broader implications debate is endless, so we should not have it in this document, else we may not get closure. Tom Henderson: Since last meeting there has been a new IRTF WG on this topic for locators and identifiers. Looking at HIp on a wide scale, and the impact. Brian: Good luck! Geoff: Persistent unique identities that are validatable and operate with integrity have a heavyweight distribution mechanism, so think about that in the context of DNS, or distributing locators. There will be a comparable infrastructure, so there are far-reaching implications. There thus has to be a real value beyond multihoming for identities agile beyond locators. Christian: Could be bad for privacy Geoff: If limited to multihoming, as cost-benefit, then session based resiliency can be done without those long lived properties. There are big architectural implications. We must choose with our eyes open. This must be documented, and this draft is one such place to do it. Erik: What are you suggesting putting in? Without saying all the tradeoffs and how to weigh them. Geoff: I think we should state dimensions and arguments, maybe 2 pages of careful writing. It's not easy, but I think it's necessary. Erik: We might not get closure though. Geoff: I'd like to document that choice space. Brian: No binding vote now as Geoff may find it's too hard to write. Are people generally feeling this is good to document. Majority agreed to documenting it. Brian: This must not become a war on this topic. Just describe the dragon. Brian: The issue of initial handshake on capability seems less contentious. Geoff: We need text on signalling, negotiation, etc. Brian: And whether per-session. Geoff: Yes. Brian: The final issue also seems clear, so should go in. Brian: Are there any other issues we missed? No input from audience, so no issues raised. Brian: I urge people to have a final think for anything missing, so Geoff can focus on editorial issues. Glance over Eliot's draft for anything architectural rather than just things to think about. Eliot: I'll provide some text. Geoff: Deadline is 2 weeks for text. I'll edit in 3 weeks. ** draft-palet-multi6-scenarios-00 (Jordi Palet) This document was written in response to a comment from Brian that such text isn't written yet. There are many scenarios: e.g. ISP, IX, enterprise, university, security, defence, emergency, SOHO, 3GPP, ad-hoc, mesh. Applications like VoIP in emergency situations is one example. There are special services and applications, e.g. GRIDs, mobility, special devices (WLAN and 3G interfaces), renumbering, real time traffic, special protocols (CDN, IDC, DNS, DHCP, etc). It would be nice to get the work adopted as a WG item, maybe to integrate it with Kurt's document. We need expertise in some areas. Kurt (chair hat off); Happy to work with this as appropriate. Brian: This document should not become like other scenarios documents that may take years to complete and become blocking factors. Brian: Is this a good idea? Is it bad? Silence from room. Brian: OK, let's continue with this. Jordi: We need 3GPP input. Terry Ernst: We could merge this document with our work on a mobility approach, we have the same motivation for fixed and mobile nodes. Brian: Jordi needs help, else the document will not improve. This should remain a personal item until at least the next revision. ** Open session on next steps: Brian: We have just over an hour left. Interim attendees should know what this is about. The interim meeting sorted 30 or so proposals into groups, and the top group turned out to be wedgelayer or Fat IP, as a shim layer. So the next step is to consolidate the work in that area. We have a proposal for progress; there are 7 drafts in this space, our goal is to get the common view of the "functions" and components. A design team of Erik Nordmark, Jari Arkko, Marcelo Bagnulo Braun, Iljitsch van Beijnum, Geoff Huston and Yukka Ylitalo has been formed and all have all agreed to serve. The goal is to get to a smaller set of proposals, without going into detailed protocol specifics. A single document should be produced for discussion at IETF61. Christian: I see three separate areas that can be studied in the wedge space; how to exchange an identifier, then the issue of ingress filtering, and how that is handled, and also the issue of by which method you choose which locators to use. These three things are essentially independent. So is one document best? Brian: You're not wrong. Christian: We could redo IP, which is the identifier space, and we use that. Or we could look at the minimal set of functions to adapt what we have today. Brian: Let's keep this on hold for the next few slides today. Brian: There are 7 drafts in this space: draft-nordmark-multi6-cb64-00.txt draft-nordmark-multi6-noid-02.txt (draft-nordmark-multi6-sim-01.txt withdrawn) draft-ylitalo-multi6-wimp-01.txt draft-crocker-mast-proposal-01.txt draft-nikander-multi6-hip-01.txt draft-van-beijnum-multi6-odt-00.txt We also looked at the mailing list for functional decompostion: Establish mh session state Locator selection for initial contact (both source and destination)   There are two items here:       - Path availability. i.e. if packets with a given pair of         source and destination address reach the other endpoint       - Policy: about locator selection Path failure detection mechanism / Trigger rehoming Locator selection after a failure has been detected / Choose new address pair Add/delete addresses Execute rehoming Delete mh session state Identifier discovery mechanism Locator discovery mechanism    - for initial contact    - once that the communication is established Identifier validation mechanism Locator validation mechanism    - at the initial contact    - once that the communication is established Garbage collection We won't discuss this point by point today as we don't have time. We missed out ingress filtering but will add it. There is a scope of around a dozen or so areas to consider, based on the observations. Kurt: We need to get a document from this decomposition as a discussion focus. Christian: Also the interoperability with existing IPv6 hosts needs to be considered. Brian: Of course. Erik: The focus needs to be to bring together the different identifier aspects, to see if we can build a method that will cover what is needed. The ingress filtering can be treated separately. Brian: This list of components shows its not an easy problem. You need to think about all the goals, all the things to think about, to get a complete problem statement. Christian: Also hardware acceleration, and load balancing, needs to be considered. Jim Bound: I'd like to see SCTP as part of the analysis. Brian: SCTP tackles some of these issues, it may not be built into the wedge layer. Jim: It may reduce the wedge. Is it part? Or are we just reinventing a 3.5 layer? Brian: we didn't list it as SCTP is Layer 4. Components are relevant though. Jim: Some of us believe we're making this too complex. I'm working also on hardware acceleration- it should be transparent to us. Vendors who ship "funny link layer interfaces" - that's their problem. We don't want to take on too much. Brian: yes, but there are tough problems with assumptions that offload devices make. Erik: We should not force all existing hardware and apps to keep working. Tony Li: This is the IETF, so we work on running code. We need to think about hardware, not ignore it. Jim: That's not what I'm saying. Christian: The wedge layer only comes into action for session survivability, but if you do not care about that, the picture is different. We should acknowledge that. Tying the 3.5 layer to session survivability has implications. Brian: I suspect that's correct. Geoff is this in the archictecture document? Do you only need wedge layer if you care about session survivability? Geoff: Yes, I thought about it as Layer 3.4 or 3.6, depending on whether you look up or down. You could swing it either way a bit, depending on whether you want to share state across sessions, with longer running glue, or have session survivability. Being agnostic leads to complexiities, there's a different functionality depending on whether a previous session exists. l lean towards 3.6. Brian: Are there common features that we don't need to discuss, or differentiating features that we do need discuss, e.g. HIP vs NOID, or are there still things missing in the "things to think about" draft? Brian: Erik, anything to say about the design team process? Erik: We're trying to organise a get-together this week, no slot yet. That's about it at the moment. We need to carve out more than we discussed today, in terms of what to cover or not cover. I'm concerned about the 7 drafts, but also continue to get input from the WG. Brian: we can identify what can be worked on independently, not everything is in the scope of the wedge layer. We could get other authors or another design team in place for that. Tim: What was the withdrawn draft of the 7 drafts? ie. draft-nordmark-multi6-sim-01. Erik: That was down to HIP, it felt redundant. Brian: The revised wimp draft is quite different now, btw. Marcelo: How will we move forward on the components part? I agree with Christian's comments here. Brian: We don't have a plan yet but need one. We need to find the gaps in our plans. Brian: We can close now if there is nothing else to raise now. Anything to add, David, as Area Director? David: Nothing to say or add. Close of meeting at 10:40am. --------------070006030406080707020606-- From owner-multi6@ops.ietf.org Mon Aug 9 09:29: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 JAA28242 for ; Mon, 9 Aug 2004 09:29:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuABZ-0000y3-2M for multi6-data@psg.com; Mon, 09 Aug 2004 13:27:33 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuABO-0000xL-CH for multi6@ops.ietf.org; Mon, 09 Aug 2004 13:27:22 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 96EC76655; Mon, 9 Aug 2004 09:27:21 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Aug 2004 09:27:21 -0400 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: multi6 wedge layer design team Date: Mon, 9 Aug 2004 09:27:41 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B06E2B5D5@tayexc13.americas.cpqcorp.net> Thread-Topic: multi6 wedge layer design team Thread-Index: AcR999o5zhJBgxXKQRi7C6BLLs5bTQAHL68g From: "Bound, Jim" To: "Brian E Carpenter" , "Multi6" Cc: "Erik Nordmark" X-OriginalArrivalTime: 09 Aug 2004 13:27:21.0337 (UTC) FILETIME=[99862E90:01C47E14] 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 I think we also need a team to work on wedge 4.5 layer. /jim=20 > -----Original Message----- > From: owner-multi6@ops.ietf.org=20 > [mailto:owner-multi6@ops.ietf.org] On Behalf Of Brian E Carpenter > Sent: Monday, August 09, 2004 5:57 AM > To: Multi6 > Cc: Erik Nordmark > Subject: multi6 wedge layer design team=20 >=20 > As mentioned in last week's meeting, the co-chairs have asked=20 > Erik Nordmark to convene a new multi6 design team to refine=20 > the "wedge layer" analysis. >=20 > Initial membership: >=20 > Erik Nordmark (convenor), Jari Arkko, Marcelo Bagnulo Braun,=20 > Iljitsch van Beijnum, Geoff Huston and Yukka Ylitalo. >=20 > The team has to be kept small for efficiency, but Erik may=20 > decide to add one or two more volunteers. >=20 > We hope for a draft ready for discussion during the November IETF. >=20 > Here's the "mission statement": >=20 > Refine wedge layer/ layer 3.5 analysis to reach an agreed=20 > approach (or very small number of approaches) and a list of=20 > functions and components needed. >=20 > The goal is to get to a much smaller set of proposals and/or=20 > a unified proposal and identify any problems with the unified=20 > direction. It is OK to document directions that can be taken=20 > to solve it but we cannot go into protocol specifics within=20 > the current WG charter. >=20 > Brian + Kurtis > multi6 cochairs >=20 >=20 >=20 >=20 From owner-multi6@ops.ietf.org Mon Aug 9 13:33:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16504 for ; Mon, 9 Aug 2004 13:33:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuDz4-0004Jd-03 for multi6-data@psg.com; Mon, 09 Aug 2004 17:30:54 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuDyr-0004Gl-7Q for multi6@ops.ietf.org; Mon, 09 Aug 2004 17:30:41 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i79HTRN08155; Mon, 9 Aug 2004 10:29:27 -0700 Date: Mon, 9 Aug 2004 10:29:18 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1827052302.20040809102918@brandenburg.com> To: "Bound, Jim" CC: "Brian E Carpenter" , "Multi6" , "Erik Nordmark" Subject: Re: multi6 wedge layer design team In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B06E2B5D5@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B06E2B5D5@tayexc13.americas.cpqcorp.net> MIME-Version: 1.0 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.6 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim, BJ> I think we also need a team to work on wedge 4.5 layer. The original definition of design team was that it was a self-organzing effort of like-minded participants. There is nothing that requires that a design team be formally organized. Folks wanting to work on wedge 4.5 layer issues are free to do so. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-multi6@ops.ietf.org Mon Aug 9 18:21: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 SAA26795 for ; Mon, 9 Aug 2004 18:21:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuITz-000Gpb-EL for multi6-data@psg.com; Mon, 09 Aug 2004 22:19:07 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuITo-000Gov-PP for multi6@ops.ietf.org; Mon, 09 Aug 2004 22:18:56 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 368286199; Mon, 9 Aug 2004 18:18:56 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Aug 2004 18:18:56 -0400 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: multi6 wedge layer design team Date: Mon, 9 Aug 2004 18:19:16 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B06E2B706@tayexc13.americas.cpqcorp.net> Thread-Topic: multi6 wedge layer design team Thread-Index: AcR+NpnZQgmsi0uDTsyjYZkzqeufZAAKCp0g From: "Bound, Jim" To: "Dave Crocker" Cc: "Brian E Carpenter" , "Multi6" , "Erik Nordmark" X-OriginalArrivalTime: 09 Aug 2004 22:18:56.0051 (UTC) FILETIME=[DC415030:01C47E5E] 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 Dave, Thanks. OK. Let me talk to some of the 4.5 believers :--) My mail in no way implied we should not look at 3.5 as a note. /jim=20 > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net]=20 > Sent: Monday, August 09, 2004 1:29 PM > To: Bound, Jim > Cc: Brian E Carpenter; Multi6; Erik Nordmark > Subject: Re: multi6 wedge layer design team >=20 > Jim, >=20 > BJ> I think we also need a team to work on wedge 4.5 layer. >=20 > The original definition of design team was that it was a > self-organzing effort of like-minded participants. >=20 > There is nothing that requires that a design team be formally > organized. >=20 > Folks wanting to work on wedge 4.5 layer issues are free to do so. >=20 >=20 > d/ > -- > Dave Crocker Brandenburg=20 > InternetWorking Sunnyvale, CA =20 > USA , >=20 >=20 From owner-multi6@ops.ietf.org Tue Aug 10 03:43: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 DAA29075 for ; Tue, 10 Aug 2004 03:43:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuRG3-000BC7-Ss for multi6-data@psg.com; Tue, 10 Aug 2004 07:41:19 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuRFs-000BBT-D5 for multi6@ops.ietf.org; Tue, 10 Aug 2004 07:41:08 +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 i7A7f2Gm076886; Tue, 10 Aug 2004 07:41:02 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 i7A7f2nP217186; Tue, 10 Aug 2004 09:41:02 +0200 Received: from zurich.ibm.com (sig-9-145-136-201.de.ibm.com [9.145.136.201]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA82702; Tue, 10 Aug 2004 09:40:59 +0200 Message-ID: <41187C0B.1050400@zurich.ibm.com> Date: Tue, 10 Aug 2004 09:40:59 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Bound, Jim" CC: Multi6 Subject: Re: multi6 wedge layer design team References: <9C422444DE99BC46B3AD3C6EAFC9711B06E2B706@tayexc13.americas.cpqcorp.net> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B06E2B706@tayexc13.americas.cpqcorp.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 The chairs didn't detect enough available effort during and after the interim meeting to launch a formal design team for the transport-layer group of proposals; however, it's quite consistent with the discussion for the transport-layer authors to get together and produce a unified draft before the next IETF. As for layer 3.5 work, it shouldn't be a protocol design, however. The transport layer drafts that we identified as a group are: 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 Brian P.S. Extract from RFC 2418: "Design teams may range from an informal chat between people in a hallway to a formal set of expert volunteers that the WG chair or AD appoints to attack a controversial problem. The output of a design team is always subject to approval, rejection or modification by the WG as a whole." Bound, Jim wrote: > Dave, > > Thanks. OK. Let me talk to some of the 4.5 believers :--) My mail in > no way implied we should not look at 3.5 as a note. > > /jim > > >>-----Original Message----- >>From: Dave Crocker [mailto:dhc@dcrocker.net] >>Sent: Monday, August 09, 2004 1:29 PM >>To: Bound, Jim >>Cc: Brian E Carpenter; Multi6; Erik Nordmark >>Subject: Re: multi6 wedge layer design team >> >>Jim, >> >>BJ> I think we also need a team to work on wedge 4.5 layer. >> >> The original definition of design team was that it was a >> self-organzing effort of like-minded participants. >> >> There is nothing that requires that a design team be formally >> organized. >> >> Folks wanting to work on wedge 4.5 layer issues are free to do so. >> >> >>d/ >>-- >> Dave Crocker Brandenburg >>InternetWorking Sunnyvale, CA >>USA , >> >> > > From owner-multi6@ops.ietf.org Wed Aug 11 12:16:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16353 for ; Wed, 11 Aug 2004 12:16:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Buvjj-000GJc-IG for multi6-data@psg.com; Wed, 11 Aug 2004 16:13:59 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuvjY-000GIs-R7 for multi6@ops.ietf.org; Wed, 11 Aug 2004 16:13:48 +0000 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA12836 for ; Wed, 11 Aug 2004 09:13:48 -0700 (PDT) Received: from XCH-NWBH-02.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 i7BGDl401988 for ; Wed, 11 Aug 2004 09:13:47 -0700 (PDT) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 09:13:46 -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: Newbie Question about addressing impacts Date: Wed, 11 Aug 2004 09:13:46 -0700 Message-ID: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.com> Thread-Topic: Draft multi6 minutes Thread-Index: AcR+BUBWMwDd0pozTZGR1bl2Zqu8owBtivSg From: "Fleischman, Eric" To: "Multi6" X-OriginalArrivalTime: 11 Aug 2004 16:13:47.0180 (UTC) FILETIME=[2E6066C0:01C47FBE] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Newbie question: Assuming a multihomed environment with N ISPs = supporting a corporate network of 2K+ routers and 200K+ computers. Is = multi6 proposing that the interfaces of the routers and computers each = have N different global addresses, one set for each of the N ISPs? If = so, has multi6 considered the impact of this approach to IGP and EGP = performance? If so, what was the consensus conclusion to that = evaluation? From owner-multi6@ops.ietf.org Wed Aug 11 13:38: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 NAA21402 for ; Wed, 11 Aug 2004 13:38:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bux2H-0001mQ-9K for multi6-data@psg.com; Wed, 11 Aug 2004 17:37:13 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bux1h-0001gW-QB for multi6@ops.ietf.org; Wed, 11 Aug 2004 17:36: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 i7BHcrMW019679; Wed, 11 Aug 2004 19:38:53 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.com> References: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Multi6" From: Iljitsch van Beijnum Subject: Re: Newbie Question about addressing impacts Date: Wed, 11 Aug 2004 19:36:33 +0200 To: "Fleischman, Eric" X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Eric, On 11-aug-04, at 18:13, Fleischman, Eric wrote: > Newbie question: Assuming a multihomed environment with N ISPs > supporting a corporate network of 2K+ routers and 200K+ computers. Is > multi6 proposing that the interfaces of the routers and computers each > have N different global addresses, one set for each of the N ISPs? At this time, multi6 isn't exactly proposing anything. But yes, pretty much everything that's under discussion right now assumes this. > If so, has multi6 considered the impact of this approach to IGP and > EGP performance? If so, what was the consensus conclusion to that > evaluation? There hasn't been an evaluation. There is a feature that I'm very much in favor of that could help here: the ability to implement a multihoming solution in middleboxes or border routers. In such a scenario, there would be a set of addresses for internal use in the site, and the proxy multihoming devices add the multihoming capability somewhere close to the border of the network. The good thing here is that there is no need to modify each individual host to obtain multihoming benefits, and it's easier to implement policy in a few central places rather than distributed over all the hosts in the network. From owner-multi6@ops.ietf.org Wed Aug 11 13:49: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 NAA22129 for ; Wed, 11 Aug 2004 13:49:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuxDw-0003VZ-1E for multi6-data@psg.com; Wed, 11 Aug 2004 17:49:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuxDM-0003Rr-QJ for multi6@ops.ietf.org; Wed, 11 Aug 2004 17:48:41 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7BHlNi31028; Wed, 11 Aug 2004 20:47:23 +0300 Date: Wed, 11 Aug 2004 20:47:23 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: "Fleischman, Eric" , Multi6 Subject: Re: Newbie Question about addressing impacts In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 11 Aug 2004, Iljitsch van Beijnum wrote: > On 11-aug-04, at 18:13, Fleischman, Eric wrote: > > > Newbie question: Assuming a multihomed environment with N ISPs > > supporting a corporate network of 2K+ routers and 200K+ computers. Is > > multi6 proposing that the interfaces of the routers and computers each > > have N different global addresses, one set for each of the N ISPs? > > At this time, multi6 isn't exactly proposing anything. But yes, pretty > much everything that's under discussion right now assumes this. I think pretty much everyone has silently made an assumption that it would be unreasonable to expect that to happen -- especially if all the hosts would need to be globally addressable (and not e.g. with unique local addresses, with global addresses only distributed to the proxy servers or whatever). The really big folks WILL get their own /32 allocation in some way or the other, I'd guess. I'm not so opposed to the idea.. just the fact that if that becomes a common practice, it'll be difficult to draw the line in RIR policies.. This is probably the case for very big enterprises who have a limited number of ISPs and Internet connection points, possibly in the same region (i.e.: all the traffic goes through 2-3 ISPs). It's slightly different if you have 100 branch offices in 100 different countries: then addressing each country's offices from each country's ISP provider address space might still be feasible. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed Aug 11 20:19: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 UAA02434 for ; Wed, 11 Aug 2004 20:19:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bv3HQ-00070L-FS for multi6-data@psg.com; Thu, 12 Aug 2004 00:17:16 +0000 Received: from [204.127.202.55] (helo=sccrmhc11.comcast.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bv3Gz-0006uv-JG for multi6@ops.ietf.org; Thu, 12 Aug 2004 00:16:49 +0000 Received: from [192.168.1.101] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (sccrmhc11) with SMTP id <20040812001638011004svvbe> (Authid: li.tony); Thu, 12 Aug 2004 00:16:48 +0000 In-Reply-To: References: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Fleischman, Eric" , "Multi6" From: Tony Li Subject: Re: Newbie Question about addressing impacts Date: Wed, 11 Aug 2004 17:16:32 -0700 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > There is a feature that I'm very much in favor of that could help > here: the ability to implement a multihoming solution in middleboxes > or border routers. In such a scenario, there would be a set of > addresses for internal use in the site, and the proxy multihoming > devices add the multihoming capability somewhere close to the border > of the network. The good thing here is that there is no need to modify > each individual host to obtain multihoming benefits, and it's easier > to implement policy in a few central places rather than distributed > over all the hosts in the network. > Architecturally, this is the right thing to do. However, it is an implicit validation of NAT, and if NAT's ok, then why do we need v6 in the first place? Ideally, in an Internet architecture that we don't have today, there would be N prefixes, one per ISP. However, the host portion of the locator would be a constant regardless of prefix. The IGP need not know about the external prefixes, so there's no issue there. The EGP is not impacted because each of the prefixes is out of the respective SP's aggregate. Tony From owner-multi6@ops.ietf.org Thu Aug 12 04:59: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 EAA14222 for ; Thu, 12 Aug 2004 04:59:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvBOm-0001vl-K6 for multi6-data@psg.com; Thu, 12 Aug 2004 08:57:24 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvBOL-0001rF-9f for multi6@ops.ietf.org; Thu, 12 Aug 2004 08:56:57 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8475A3A187; Thu, 12 Aug 2004 10:56:55 +0200 (CEST) Received: from [163.117.252.220] (vpn-252-220.uc3m.es [163.117.252.220]) by smtp01.uc3m.es (Postfix) with ESMTP id C816B3A183; Thu, 12 Aug 2004 10:56:54 +0200 (CEST) In-Reply-To: References: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.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: "Multi6" , "Fleischman, Eric" From: marcelo bagnulo braun Subject: Re: Newbie Question about addressing impacts Date: Thu, 12 Aug 2004 10:58:56 +0200 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 11/08/2004, a las 19:36, Iljitsch van Beijnum escribi=F3: > Hi Eric, > > On 11-aug-04, at 18:13, Fleischman, Eric wrote: > >> Newbie question: Assuming a multihomed environment with N ISPs=20 >> supporting a corporate network of 2K+ routers and 200K+ computers. Is=20= >> multi6 proposing that the interfaces of the routers and computers=20 >> each have N different global addresses, one set for each of the N=20 >> ISPs? > > At this time, multi6 isn't exactly proposing anything. But yes, pretty=20= > much everything that's under discussion right now assumes this. > >> If so, has multi6 considered the impact of this approach to IGP and=20= >> EGP performance? If so, what was the consensus conclusion to that=20 >> evaluation? > > There hasn't been an evaluation. > > There is a feature that I'm very much in favor of that could help=20 > here: the ability to implement a multihoming solution in middleboxes=20= > or border routers. In such a scenario, there would be a set of=20 > addresses for internal use in the site, and the proxy multihoming=20 > devices add the multihoming capability somewhere close to the border=20= > of the network. The good thing here is that there is no need to modify=20= > each individual host to obtain multihoming benefits, and it's easier=20= > to implement policy in a few central places rather than distributed=20 > over all the hosts in the network. > Well, even if you do a per host locator selection you can still manage=20= policy in a centralized fashion, if we define proper mechanisms to=20 perform policy distribution, for instance a dhcp option for=20 distributing RFC3484 policy table or something similar. However, i=20 don't know how you can enforce policy in a centralized manner when=20 locator selection is performed by the end hosts. anyway, i agree that proxys are attractive, especially for supporting=20 advanced features like session survivability in legacy hosts regards, marcelo > From owner-multi6@ops.ietf.org Thu Aug 12 05:00: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 FAA14267 for ; Thu, 12 Aug 2004 05:00:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvBPl-00026W-Un for multi6-data@psg.com; Thu, 12 Aug 2004 08:58:25 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvBPb-00024v-9h for multi6@ops.ietf.org; Thu, 12 Aug 2004 08:58:15 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7AB663A189; Thu, 12 Aug 2004 10:58:14 +0200 (CEST) Received: from [163.117.252.220] (vpn-252-220.uc3m.es [163.117.252.220]) by smtp01.uc3m.es (Postfix) with ESMTP id B60673A187; Thu, 12 Aug 2004 10:58:13 +0200 (CEST) In-Reply-To: References: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <06F14308-EC3E-11D8-9FC6-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Iljitsch van Beijnum , "Multi6" , "Fleischman, Eric" From: marcelo bagnulo braun Subject: Re: Newbie Question about addressing impacts Date: Thu, 12 Aug 2004 11:00:15 +0200 To: Tony Li X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 12/08/2004, a las 2:16, Tony Li escribi=F3: >> There is a feature that I'm very much in favor of that could help=20 >> here: the ability to implement a multihoming solution in middleboxes=20= >> or border routers. In such a scenario, there would be a set of=20 >> addresses for internal use in the site, and the proxy multihoming=20 >> devices add the multihoming capability somewhere close to the border=20= >> of the network. The good thing here is that there is no need to=20 >> modify each individual host to obtain multihoming benefits, and it's=20= >> easier to implement policy in a few central places rather than=20 >> distributed over all the hosts in the network. >> > > > Architecturally, this is the right thing to do. However, it is an=20 > implicit validation of NAT, and if NAT's ok, > then why do we need v6 in the first place? > > Ideally, in an Internet architecture that we don't have today, there=20= > would be N prefixes, one per ISP. However, the host > portion of the locator would be a constant regardless of prefix. The=20= > IGP need not know about the external prefixes, so there's > no issue there. Good point. But this implies modifying IGPs, right? regards, marcelo > The EGP is not impacted because each of the prefixes is out of the=20= > respective SP's aggregate. > > Tony > > From owner-multi6@ops.ietf.org Thu Aug 12 06:14: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 GAA18390 for ; Thu, 12 Aug 2004 06:14:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvCa9-000FFP-8M for multi6-data@psg.com; Thu, 12 Aug 2004 10:13:13 +0000 Received: from [216.148.227.85] (helo=rwcrmhc12.comcast.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvCZq-000FAf-L6 for multi6@ops.ietf.org; Thu, 12 Aug 2004 10:12:54 +0000 Received: from [192.168.1.101] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (rwcrmhc12) with SMTP id <2004081210124201400r1h2le> (Authid: li.tony); Thu, 12 Aug 2004 10:12:54 +0000 In-Reply-To: <06F14308-EC3E-11D8-9FC6-000D93ACD0FE@it.uc3m.es> References: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.com> <06F14308-EC3E-11D8-9FC6-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <241D2294-EC48-11D8-B8D4-000A95D1475E@tony.li> Content-Transfer-Encoding: 7bit Cc: Iljitsch van Beijnum , "Multi6" , "Fleischman, Eric" From: Tony Li Subject: Re: Newbie Question about addressing impacts Date: Thu, 12 Aug 2004 03:12:39 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Ideally, in an Internet architecture that we don't have today, there >> would be N prefixes, one per ISP. However, the host >> portion of the locator would be a constant regardless of prefix. The >> IGP need not know about the external prefixes, so there's >> no issue there. > > Good point. > > But this implies modifying IGPs, right? > Not seriously. You would be modifying them to carry around a constant local portion of the address and ignore the "global" prefix. Simply picking a single constant prefix for use internally would suffice. Tony From owner-multi6@ops.ietf.org Thu Aug 12 06:47: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 GAA20900 for ; Thu, 12 Aug 2004 06:47:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvD6K-000JOc-Ao for multi6-data@psg.com; Thu, 12 Aug 2004 10:46:28 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvD5l-000JHY-Jq for multi6@ops.ietf.org; Thu, 12 Aug 2004 10:45:53 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3A5153A2C0; Thu, 12 Aug 2004 12:45:52 +0200 (CEST) Received: from [163.117.252.220] (vpn-252-220.uc3m.es [163.117.252.220]) by smtp01.uc3m.es (Postfix) with ESMTP id 611573A2C3; Thu, 12 Aug 2004 12:45:51 +0200 (CEST) In-Reply-To: <241D2294-EC48-11D8-B8D4-000A95D1475E@tony.li> References: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.com> <06F14308-EC3E-11D8-9FC6-000D93ACD0FE@it.uc3m.es> <241D2294-EC48-11D8-B8D4-000A95D1475E@tony.li> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <0FFA6B18-EC4D-11D8-9FC6-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Iljitsch van Beijnum , "Multi6" , "Fleischman, Eric" From: marcelo bagnulo braun Subject: Re: Newbie Question about addressing impacts Date: Thu, 12 Aug 2004 12:47:53 +0200 To: Tony Li X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 12/08/2004, a las 12:12, Tony Li escribi=F3: >>> Ideally, in an Internet architecture that we don't have today, there=20= >>> would be N prefixes, one per ISP. However, the host >>> portion of the locator would be a constant regardless of prefix. =20 >>> The IGP need not know about the external prefixes, so there's >>> no issue there. >> >> Good point. >> >> But this implies modifying IGPs, right? >> > > > Not seriously. You would be modifying them to carry around a constant=20= > local portion of the address and ignore the "global" > prefix. Simply picking a single constant prefix for use internally=20 > would suffice. > so are you assuming that hosts within the multihomed site are not aware=20= of their own global prefixes, so they only use this local prefix and=20 that global prefixes are stuffed by exit routers "a la" GSE? I was more thinking in that hosts are aware of their own global=20 prefixes and that they use them within the site, but intr site routers=20= know which are the local prefixes, so when the see a destination=20 address that contains one of them, it just ignores the global part=20 (/48) and just routes according to the bits between the /48 and the=20 /64. this implies that router have to know which are the global prefixes=20 assigned to the site and for that case route based on the subnet bits. (that is why i thought that some change to the intra site routing was=20 needed) regards, marcelo > Tony > From owner-multi6@ops.ietf.org Thu Aug 12 09:34: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 JAA01176 for ; Thu, 12 Aug 2004 09:34:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvFgz-000Dgm-OV for multi6-data@psg.com; Thu, 12 Aug 2004 13:32:29 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvFgh-000Dds-0C for multi6@ops.ietf.org; Thu, 12 Aug 2004 13:32:11 +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 GAA23957; Thu, 12 Aug 2004 06:31:56 -0700 (PDT) Received: from XCH-NWBH-02.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 i7CDVtc16771; Thu, 12 Aug 2004 08:31:55 -0500 (CDT) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Aug 2004 06:31:54 -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: Newbie Question about addressing impacts Date: Thu, 12 Aug 2004 06:31:54 -0700 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDD6CC@xch-nw-09.nw.nos.boeing.com> Thread-Topic: Newbie Question about addressing impacts Thread-Index: AcSASlNwCnPqggOnRouXLEEaVxxYzAAJd4sg From: "Fleischman, Eric" To: "marcelo bagnulo braun" , "Iljitsch van Beijnum" Cc: "Multi6" X-OriginalArrivalTime: 12 Aug 2004 13:31:54.0773 (UTC) FILETIME=[BBBE7450:01C48070] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable This is an interesting idea. However, if we embed proxy functions into = border routers it would potentially add overhead (as well as latency) = and make them harder to manage. Specifically, the number of border = routers is likely to increase as network perimeters become more porous. = Thus, this idea carries with it the need to ensure that these = distributed routers can be configured with consistent policies. Simple is good in operations. -----Original Message----- From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] Sent: Thursday, August 12, 2004 1:59 AM To: Iljitsch van Beijnum Cc: Multi6; Fleischman, Eric Subject: Re: Newbie Question about addressing impacts El 11/08/2004, a las 19:36, Iljitsch van Beijnum escribi=F3: > Hi Eric, > > On 11-aug-04, at 18:13, Fleischman, Eric wrote: > >> Newbie question: Assuming a multihomed environment with N ISPs=20 >> supporting a corporate network of 2K+ routers and 200K+ computers. Is = >> multi6 proposing that the interfaces of the routers and computers=20 >> each have N different global addresses, one set for each of the N=20 >> ISPs? > > At this time, multi6 isn't exactly proposing anything. But yes, pretty = > much everything that's under discussion right now assumes this. > >> If so, has multi6 considered the impact of this approach to IGP and=20 >> EGP performance? If so, what was the consensus conclusion to that=20 >> evaluation? > > There hasn't been an evaluation. > > There is a feature that I'm very much in favor of that could help=20 > here: the ability to implement a multihoming solution in middleboxes=20 > or border routers. In such a scenario, there would be a set of=20 > addresses for internal use in the site, and the proxy multihoming=20 > devices add the multihoming capability somewhere close to the border=20 > of the network. The good thing here is that there is no need to modify = > each individual host to obtain multihoming benefits, and it's easier=20 > to implement policy in a few central places rather than distributed=20 > over all the hosts in the network. > Well, even if you do a per host locator selection you can still manage=20 policy in a centralized fashion, if we define proper mechanisms to=20 perform policy distribution, for instance a dhcp option for=20 distributing RFC3484 policy table or something similar. However, i=20 don't know how you can enforce policy in a centralized manner when=20 locator selection is performed by the end hosts. anyway, i agree that proxys are attractive, especially for supporting=20 advanced features like session survivability in legacy hosts regards, marcelo > From owner-multi6@ops.ietf.org Thu Aug 12 10:08:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03253 for ; Thu, 12 Aug 2004 10:08:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvGF5-000ILj-Fl for multi6-data@psg.com; Thu, 12 Aug 2004 14:07:43 +0000 Received: from [210.150.154.240] (helo=mpb3.plala.or.jp) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvGEu-000IKe-Er for multi6@ops.ietf.org; Thu, 12 Aug 2004 14:07:32 +0000 Received: from [192.168.1.7] ([218.47.131.161]) by mpb3.plala.or.jp with ESMTP id <20040812140730.ROXI28348.mpb3.plala.or.jp@[192.168.1.7]> for ; Thu, 12 Aug 2004 23:07:30 +0900 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Arifumi Matsumoto Subject: Re: Newbie Question about addressing impacts Date: Thu, 12 Aug 2004 23:07:30 +0900 To: multi6@ops.ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Oops, I forgot to send CC to multi6. -- Hi marcelo, > Well, even if you do a per host locator selection you can still manage > policy in a centralized fashion, if we define proper mechanisms to > perform policy distribution, for instance a dhcp option for > distributing RFC3484 policy table or something similar. However, i > don't know how you can enforce policy in a centralized manner when > locator selection is performed by the end hosts. I believe that such a mechanism for policy distribution is really important. By making use of the existing RFC3484 framework, IMHO we can develop much manageable multi-home environment in a simple and easy manner. Now I'm working on this mechanism to publish a new I-D. But I'm not sure such kind of topic is appropriate for this WG or not. I believe this part of the technology should be necessary for some of the proposals discussed here, though. -- Arifumi Matsumoto Ubiquitous Computing Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net From owner-multi6@ops.ietf.org Thu Aug 12 10:17: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 KAA04374 for ; Thu, 12 Aug 2004 10:17:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvGOM-000JW1-P7 for multi6-data@psg.com; Thu, 12 Aug 2004 14:17:18 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvGOB-000JRu-H8 for multi6@ops.ietf.org; Thu, 12 Aug 2004 14:17:08 +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 i7CEGqGP154152; Thu, 12 Aug 2004 14:16:52 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 i7CEGpjo217066; Thu, 12 Aug 2004 16:16:51 +0200 Received: from zurich.ibm.com (sig-9-145-133-10.de.ibm.com [9.145.133.10]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA35874; Thu, 12 Aug 2004 16:16:41 +0200 Message-ID: <411B7BC8.6000301@zurich.ibm.com> Date: Thu, 12 Aug 2004 16:16:40 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Tony Li CC: marcelo bagnulo braun , Iljitsch van Beijnum , Multi6 , "Fleischman, Eric" Subject: Re: Newbie Question about addressing impacts References: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.com> <06F14308-EC3E-11D8-9FC6-000D93ACD0FE@it.uc3m.es> <241D2294-EC48-11D8-B8D4-000A95D1475E@tony.li> In-Reply-To: <241D2294-EC48-11D8-B8D4-000A95D1475E@tony.li> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Li wrote: >>> Ideally, in an Internet architecture that we don't have today, there >>> would be N prefixes, one per ISP. However, the host >>> portion of the locator would be a constant regardless of prefix. The >>> IGP need not know about the external prefixes, so there's >>> no issue there. >> >> >> Good point. >> >> But this implies modifying IGPs, right? >> > > > Not seriously. You would be modifying them to carry around a constant > local portion of the address and ignore the "global" > prefix. Simply picking a single constant prefix for use internally > would suffice. Hence draft-ietf-ipv6-unique-local-addr-05.txt I'd also like to observe that running with multiple simultaneous prefixes (with its consequences for DNS and routing) has always been part of IPv6; it's not a result of hypothetical multi6 solutions. I also tend to agree that very large enterprises (such as I and Eric happen to work for) may be best served by simply getting a /32, but there are many medium size enterprises for which this is not true, and that is exactly why we are running this WG. Brian Brian From owner-multi6@ops.ietf.org Thu Aug 12 10:27: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 KAA05241 for ; Thu, 12 Aug 2004 10:27:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvGXw-000Knq-NI for multi6-data@psg.com; Thu, 12 Aug 2004 14:27:12 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvGXl-000Klu-EZ for multi6@ops.ietf.org; Thu, 12 Aug 2004 14:27:02 +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 i7CEQoGm086888; Thu, 12 Aug 2004 14:26:50 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 i7CEQnjo218390; Thu, 12 Aug 2004 16:26:49 +0200 Received: from zurich.ibm.com (sig-9-145-133-10.de.ibm.com [9.145.133.10]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA20746; Thu, 12 Aug 2004 16:26:47 +0200 Message-ID: <411B7E26.2030008@zurich.ibm.com> Date: Thu, 12 Aug 2004 16:26:46 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Arifumi Matsumoto CC: multi6@ops.ietf.org Subject: Re: Newbie Question about addressing impacts References: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit One of the components we have already identified (see the minutes from San Diego) is Locator selection after a failure has been detected / Choose new address pair RFC 3484 policy distribution might be a possible solution for that component. We aren't chartered to do basic design in this WG, but it would certainly be good to see proof-of-concept for this (and every) component. Brian Arifumi Matsumoto wrote: > Oops, I forgot to send CC to multi6. > > -- > Hi marcelo, > >> Well, even if you do a per host locator selection you can still manage >> policy in a centralized fashion, if we define proper mechanisms to >> perform policy distribution, for instance a dhcp option for >> distributing RFC3484 policy table or something similar. However, i >> don't know how you can enforce policy in a centralized manner when >> locator selection is performed by the end hosts. > > > I believe that such a mechanism for policy distribution > is really important. By making use of the existing RFC3484 > framework, IMHO we can develop much manageable multi-home > environment in a simple and easy manner. > > Now I'm working on this mechanism to publish a new I-D. > But I'm not sure such kind of topic is appropriate for > this WG or not. I believe this part of the technology should > be necessary for some of the proposals discussed here, though. > > -- > Arifumi Matsumoto > Ubiquitous Computing Project > NTT Information Sharing Platform Laboratories > E-mail: arifumi@nttv6.net > > From owner-multi6@ops.ietf.org Thu Aug 12 13:49: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 NAA18904 for ; Thu, 12 Aug 2004 13:49:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvJfP-000L7O-Po for multi6-data@psg.com; Thu, 12 Aug 2004 17:47:07 +0000 Received: from [204.127.198.35] (helo=rwcrmhc11.comcast.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvJer-000L1r-3K for multi6@ops.ietf.org; Thu, 12 Aug 2004 17:46:33 +0000 Received: from [192.168.1.101] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (rwcrmhc11) with SMTP id <200408121746240130015vrqe> (Authid: li.tony); Thu, 12 Aug 2004 17:46:32 +0000 In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDD6CC@xch-nw-09.nw.nos.boeing.com> References: <5B58696DB20B9140AD20E0685C573A6404FDD6CC@xch-nw-09.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <81470BA1-EC87-11D8-B8D4-000A95D1475E@tony.li> Content-Transfer-Encoding: 7bit Cc: "marcelo bagnulo braun" , "Iljitsch van Beijnum" , "Multi6" From: Tony Li Subject: Re: Newbie Question about addressing impacts Date: Thu, 12 Aug 2004 10:46:14 -0700 To: "Fleischman, Eric" X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Aug 12, 2004, at 6:31 AM, Fleischman, Eric wrote: > This is an interesting idea. However, if we embed proxy functions into > border routers it would potentially add overhead (as well as latency) > and make them harder to manage. Specifically, the number of border > routers is likely to increase as network perimeters become more > porous. Thus, this idea carries with it the need to ensure that these > distributed routers can be configured with consistent policies. > > Simple is good in operations. > Well, then the other architectural alternative that I can see is to embed NAT-like functionality in all of the hosts. I find this scarier. Tony From owner-multi6@ops.ietf.org Fri Aug 13 04:04: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 EAA26471 for ; Fri, 13 Aug 2004 04:04:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvX0L-0003I4-M0 for multi6-data@psg.com; Fri, 13 Aug 2004 08:01:37 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvX0A-0003ER-6u for multi6@ops.ietf.org; Fri, 13 Aug 2004 08:01:26 +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 i7D81N69153402 for ; Fri, 13 Aug 2004 08:01:23 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 i7D81NcL046140 for ; Fri, 13 Aug 2004 10:01:23 +0200 Received: from zurich.ibm.com (sig-9-145-130-225.de.ibm.com [9.145.130.225]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA25374 for ; Fri, 13 Aug 2004 10:01:22 +0200 Message-ID: <411C7551.4050201@zurich.ibm.com> Date: Fri, 13 Aug 2004 10:01:21 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: Newbie Question about addressing impacts References: <5B58696DB20B9140AD20E0685C573A6404FDD6CC@xch-nw-09.nw.nos.boeing.com> <81470BA1-EC87-11D8-B8D4-000A95D1475E@tony.li> In-Reply-To: <81470BA1-EC87-11D8-B8D4-000A95D1475E@tony.li> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Li wrote: > > On Aug 12, 2004, at 6:31 AM, Fleischman, Eric wrote: > >> This is an interesting idea. However, if we embed proxy functions into >> border routers it would potentially add overhead (as well as latency) >> and make them harder to manage. Specifically, the number of border >> routers is likely to increase as network perimeters become more >> porous. Thus, this idea carries with it the need to ensure that these >> distributed routers can be configured with consistent policies. >> >> Simple is good in operations. >> > > > Well, then the other architectural alternative that I can see is to > embed NAT-like functionality in all of the hosts. > > I find this scarier. Chair hat off: I repeat my comment from when I first saw Mike O'Dell's original 8+8 proposal: "It's architected NAT." I think anything that massages locators, whether it's in the host stack or in a proxy, comes down to architected NAT. Which means there is going to be state, so that the massage can be reversed, so that the ULP always sees the same e2e identifier. It's a design choice whether that state is in hosts, proxies, or both. Actually, we're kidding ourselves if we don't admit that this is what we are going to end up doing. Chair hat on: The design team has been asked to develop one specific approach to this, namely the IP wedge layer approach, because that is where the proposals and interest in the WG seem to be concentrated. Brian From owner-multi6@ops.ietf.org Fri Aug 13 05:30: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 FAA00141 for ; Fri, 13 Aug 2004 05:30:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvYNJ-000EdX-UP for multi6-data@psg.com; Fri, 13 Aug 2004 09:29:25 +0000 Received: from [204.127.198.39] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvYN8-000EZH-VM for multi6@ops.ietf.org; Fri, 13 Aug 2004 09:29:14 +0000 Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (rwcrmhc13) with SMTP id <20040813092914015008ueb6e> (Authid: li.tony); Fri, 13 Aug 2004 09:29:14 +0000 In-Reply-To: <411C7551.4050201@zurich.ibm.com> References: <5B58696DB20B9140AD20E0685C573A6404FDD6CC@xch-nw-09.nw.nos.boeing.com> <81470BA1-EC87-11D8-B8D4-000A95D1475E@tony.li> <411C7551.4050201@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <39266EE5-ED0B-11D8-B8D4-000A95D1475E@tony.li> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Tony Li Subject: Re: Newbie Question about addressing impacts Date: Fri, 13 Aug 2004 02:29:06 -0700 To: Brian E Carpenter X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I repeat my comment from when I first saw Mike O'Dell's original 8+8 > proposal: "It's architected NAT." I think anything that massages > locators, > whether it's in the host stack or in a proxy, comes down to architected > NAT. Which means there is going to be state, so that the massage can be > reversed, so that the ULP always sees the same e2e identifier. It's a > design choice whether that state is in hosts, proxies, or both. > > Actually, we're kidding ourselves if we don't admit that this is what > we are going to end up doing. > I think that it is vitally important that we all understand this and how we got here. If we want a host to respond flexibly to multiple addresses, then either (a) the protocol stack needs to know about the various addresses and can swap between them on the fly, OR (b) something NATty outside of the protocol stack has to "fool" the protocol stack into responding consistently. Years ago, we rejected (a) on the grounds that it would change IPv6. Folks who want to reject (b) now need to understand that they will be rejecting the entire solution space... Tony From owner-multi6@ops.ietf.org Fri Aug 13 06:16: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 GAA03246 for ; Fri, 13 Aug 2004 06:16:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvZ6G-000LKR-8D for multi6-data@psg.com; Fri, 13 Aug 2004 10:15:52 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvZ65-000LJF-3z for multi6@ops.ietf.org; Fri, 13 Aug 2004 10:15:41 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E7C0D2A19F; Fri, 13 Aug 2004 12:15:39 +0200 (CEST) Received: from arpa.it.uc3m.es (arpa.it.uc3m.es [163.117.139.120]) by smtp03.uc3m.es (Postfix) with ESMTP id C79A92A163; Fri, 13 Aug 2004 12:15:39 +0200 (CEST) Received: from violin.it.uc3m.es (violin.it.uc3m.es [163.117.139.250]) by arpa.it.uc3m.es (8.9.3/8.9.3) with ESMTP id MAA29274; Fri, 13 Aug 2004 12:15:39 +0200 Received: from [163.117.252.220] (vpn-252-220.uc3m.es [163.117.252.220]) by violin.it.uc3m.es (8.9.3p2/8.9.3/Debian 8.9.3-21) with ESMTP id MAA01309; Fri, 13 Aug 2004 12:15:29 +0200 X-Authentication-Warning: violin.it.uc3m.es: Host vpn-252-220.uc3m.es [163.117.252.220] claimed to be [163.117.252.220] In-Reply-To: <39266EE5-ED0B-11D8-B8D4-000A95D1475E@tony.li> References: <5B58696DB20B9140AD20E0685C573A6404FDD6CC@xch-nw-09.nw.nos.boeing.com> <81470BA1-EC87-11D8-B8D4-000A95D1475E@tony.li> <411C7551.4050201@zurich.ibm.com> <39266EE5-ED0B-11D8-B8D4-000A95D1475E@tony.li> 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 , Brian E Carpenter From: marcelo bagnulo braun Subject: Re: Newbie Question about addressing impacts Date: Fri, 13 Aug 2004 12:16:42 +0200 To: Tony Li X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 13/08/2004, a las 11:29, Tony Li escribi=F3: >> I repeat my comment from when I first saw Mike O'Dell's original 8+8 >> proposal: "It's architected NAT." I think anything that massages=20 >> locators, >> whether it's in the host stack or in a proxy, comes down to=20 >> architected >> NAT. Which means there is going to be state, so that the massage can=20= >> be >> reversed, so that the ULP always sees the same e2e identifier. It's a >> design choice whether that state is in hosts, proxies, or both. >> >> Actually, we're kidding ourselves if we don't admit that this is what >> we are going to end up doing. >> > > > I think that it is vitally important that we all understand this and > how we got here. If we want a host to respond flexibly to > multiple addresses, then either (a) the protocol stack needs to know=20= > about > the various addresses and can swap between them on the fly, OR > (b) something NATty outside of the protocol stack has to "fool" the=20 > protocol > stack into responding consistently. > > Years ago, we rejected (a) on the grounds that it would change IPv6. > Well, my understanding is that this is still a valid approach to the=20 problem, and i didn't get the feeling that we have rejected it (at=20 least since i am in this wg), so, may i ask why did you reject this=20 approach? > Folks who want to reject (b) now need to understand that they will be=20= > rejecting > the entire solution space... > Yes, FWIW, i agree that these are the two options regards, marcelo > Tony > > From owner-multi6@ops.ietf.org Fri Aug 13 06: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 GAA03848 for ; Fri, 13 Aug 2004 06:22:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvZCI-000M91-E7 for multi6-data@psg.com; Fri, 13 Aug 2004 10:22:06 +0000 Received: from [204.127.198.35] (helo=rwcrmhc11.comcast.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvZBz-000M7Z-Sk for multi6@ops.ietf.org; Fri, 13 Aug 2004 10:21:47 +0000 Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (rwcrmhc11) with SMTP id <2004081310214101300159jte> (Authid: li.tony); Fri, 13 Aug 2004 10:21:45 +0000 In-Reply-To: References: <5B58696DB20B9140AD20E0685C573A6404FDD6CC@xch-nw-09.nw.nos.boeing.com> <81470BA1-EC87-11D8-B8D4-000A95D1475E@tony.li> <411C7551.4050201@zurich.ibm.com> <39266EE5-ED0B-11D8-B8D4-000A95D1475E@tony.li> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8D217CC4-ED12-11D8-B8D4-000A95D1475E@tony.li> Content-Transfer-Encoding: 7bit Cc: Multi6 , Brian E Carpenter From: Tony Li Subject: Re: Newbie Question about addressing impacts Date: Fri, 13 Aug 2004 03:21:34 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Years ago, we rejected (a) on the grounds that it would change IPv6 > > Well, my understanding is that this is still a valid approach to the > problem, and i didn't get the feeling that we have rejected it (at > least since i am in this wg), so, may i ask why did you reject this > approach? Umm.... as I alluded "we" (not I ;-) rejected this approach because there are existing IPv6 host implementations. Those would have to be 'revised' to support this model. At the time, the WG felt that this was unacceptable. Tony From owner-multi6@ops.ietf.org Fri Aug 13 06:45: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 GAA05217 for ; Fri, 13 Aug 2004 06:45:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvZXV-000PZE-LQ for multi6-data@psg.com; Fri, 13 Aug 2004 10:44:01 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvZXK-000PXW-SW for multi6@ops.ietf.org; Fri, 13 Aug 2004 10:43:51 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D6A5C2A150; Fri, 13 Aug 2004 12:43:49 +0200 (CEST) Received: from arpa.it.uc3m.es (arpa.it.uc3m.es [163.117.139.120]) by smtp03.uc3m.es (Postfix) with ESMTP id BCFEF2A140; Fri, 13 Aug 2004 12:43:49 +0200 (CEST) Received: from violin.it.uc3m.es (violin.it.uc3m.es [163.117.139.250]) by arpa.it.uc3m.es (8.9.3/8.9.3) with ESMTP id MAA01825; Fri, 13 Aug 2004 12:43:49 +0200 Received: from [163.117.252.220] (vpn-252-220.uc3m.es [163.117.252.220]) by violin.it.uc3m.es (8.9.3p2/8.9.3/Debian 8.9.3-21) with ESMTP id MAA06493; Fri, 13 Aug 2004 12:43:43 +0200 X-Authentication-Warning: violin.it.uc3m.es: Host vpn-252-220.uc3m.es [163.117.252.220] claimed to be [163.117.252.220] In-Reply-To: <8D217CC4-ED12-11D8-B8D4-000A95D1475E@tony.li> References: <5B58696DB20B9140AD20E0685C573A6404FDD6CC@xch-nw-09.nw.nos.boeing.com> <81470BA1-EC87-11D8-B8D4-000A95D1475E@tony.li> <411C7551.4050201@zurich.ibm.com> <39266EE5-ED0B-11D8-B8D4-000A95D1475E@tony.li> <8D217CC4-ED12-11D8-B8D4-000A95D1475E@tony.li> 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 , Brian E Carpenter From: marcelo bagnulo braun Subject: Re: Newbie Question about addressing impacts Date: Fri, 13 Aug 2004 12:45:00 +0200 To: Tony Li X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 13/08/2004, a las 12:21, Tony Li escribi=F3: > > > >>> Years ago, we rejected (a) on the grounds that it would change IPv6 >> >> Well, my understanding is that this is still a valid approach to the=20= >> problem, and i didn't get the feeling that we have rejected it (at=20 >> least since i am in this wg), so, may i ask why did you reject this=20= >> approach? > > > Umm.... as I alluded "we" (not I ;-) rejected this approach because=20 > there are existing > IPv6 host implementations. Those would have to be 'revised' to=20 > support this model. > At the time, the WG felt that this was unacceptable. > Ok. But currently, i think that it seems clear that any of the both=20 approaches will require modifications in both ends of the=20 communication. I mean, any solution for preserving established sessions will impose=20 modifications in both ends, mainly because security issues, so i guess=20= that from this p.o.v. both approaches are equally acceptable, right? regards, marcelo > Tony > From owner-multi6@ops.ietf.org Fri Aug 13 07:22: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 HAA06914 for ; Fri, 13 Aug 2004 07:22:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bva7o-000506-TH for multi6-data@psg.com; Fri, 13 Aug 2004 11:21:32 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bva7d-0004zB-NB for multi6@ops.ietf.org; Fri, 13 Aug 2004 11:21:22 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 265DD282FB; Fri, 13 Aug 2004 13:21:20 +0200 (CEST) Received: from arpa.it.uc3m.es (arpa.it.uc3m.es [163.117.139.120]) by smtp02.uc3m.es (Postfix) with ESMTP id 0AF28282F9; Fri, 13 Aug 2004 13:21:20 +0200 (CEST) Received: from violin.it.uc3m.es (violin.it.uc3m.es [163.117.139.250]) by arpa.it.uc3m.es (8.9.3/8.9.3) with ESMTP id NAA09750; Fri, 13 Aug 2004 13:21:19 +0200 Received: from [163.117.252.220] (vpn-252-220.uc3m.es [163.117.252.220]) by violin.it.uc3m.es (8.9.3p2/8.9.3/Debian 8.9.3-21) with ESMTP id NAA00978; Fri, 13 Aug 2004 13:21:17 +0200 X-Authentication-Warning: violin.it.uc3m.es: Host vpn-252-220.uc3m.es [163.117.252.220] claimed to be [163.117.252.220] In-Reply-To: <411B7E26.2030008@zurich.ibm.com> References: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.com> <411B7E26.2030008@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <1BB1D8B2-ED1B-11D8-9FC6-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Arifumi Matsumoto , multi6@ops.ietf.org From: marcelo bagnulo braun Subject: Re: Newbie Question about addressing impacts Date: Fri, 13 Aug 2004 13:22:49 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Brian, Arifumi, I am not sure that the policy table falls under this particular=20 component, since as i see it, the policy table is more related with=20 locator selection when there are no failures and it is used as a mean=20 to express administrative prefferences. Anyway, as i understand it, Arifumi is considering mechanisms to=20 distribute RFC3484 policy table, so this is not really related to=20 locator selection, but rather with centralized policy management. IMHO this will be a requirement, especially as the sites grow bigger,=20 because manually configuring the policy table of each hosts doesn't=20 seems a reasonable approach when there is a considerable number of=20 hosts. Well, in any case, i can see basically two options to provide automatic=20= configuration of RFC3484 policy table: - router Advertisement - dhcp option the porblem with RA is that the full policy table has to fit in a=20 single RA message, since imho the distribution of the policy table=20 should be atomic (having only part of the policy table configure may=20 cause undesired behaviour), in addition, RA requires the configuration=20= of the policy table in at least one router per link, which may be=20 cumbersome the problem with dhcp is that you need a dhcp server, but it provides=20 most of the desired features AFAICS imho, a policy distribution mechanism will be needed at some moment. We have made a couple of implementations in linux of the two policy=20 table distribution mechanisms, one using dhcp and another one using RA,=20= to see how this work. If anyone is interested, we can discuss it. Regards, marcelo El 12/08/2004, a las 16:26, Brian E Carpenter escribi=F3: > One of the components we have already identified (see the minutes > from San Diego) is > > Locator selection after a failure has been detected / Choose new=20 > address pair > > RFC 3484 policy distribution might be a possible solution > for that component. We aren't chartered to do basic design in > this WG, but it would certainly be good to see proof-of-concept > for this (and every) component. > > Brian > > > Arifumi Matsumoto wrote: >> Oops, I forgot to send CC to multi6. >> --=20 >> Hi marcelo, >>> Well, even if you do a per host locator selection you can still=20 >>> manage policy in a centralized fashion, if we define proper=20 >>> mechanisms to perform policy distribution, for instance a dhcp=20 >>> option for distributing RFC3484 policy table or something similar.=20= >>> However, i don't know how you can enforce policy in a centralized=20 >>> manner when locator selection is performed by the end hosts. >> I believe that such a mechanism for policy distribution >> is really important. By making use of the existing RFC3484 >> framework, IMHO we can develop much manageable multi-home >> environment in a simple and easy manner. >> Now I'm working on this mechanism to publish a new I-D. >> But I'm not sure such kind of topic is appropriate for >> this WG or not. I believe this part of the technology should >> be necessary for some of the proposals discussed here, though. >> --=20 >> Arifumi Matsumoto >> Ubiquitous Computing Project >> NTT Information Sharing Platform Laboratories >> E-mail: arifumi@nttv6.net > From owner-multi6@ops.ietf.org Fri Aug 13 07:35: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 HAA07394 for ; Fri, 13 Aug 2004 07:35:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvaKK-0006bJ-FR for multi6-data@psg.com; Fri, 13 Aug 2004 11:34:28 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvaK9-0006Xw-D1 for multi6@ops.ietf.org; Fri, 13 Aug 2004 11:34:17 +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 i7DBYFgB107368; Fri, 13 Aug 2004 11:34:15 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 i7DBYE2x220132; Fri, 13 Aug 2004 13:34:14 +0200 Received: from zurich.ibm.com (sig-9-145-130-225.de.ibm.com [9.145.130.225]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA92598; Fri, 13 Aug 2004 13:34:13 +0200 Message-ID: <411CA734.6030309@zurich.ibm.com> Date: Fri, 13 Aug 2004 13:34:12 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Tony Li CC: marcelo bagnulo braun , Multi6 Subject: Re: Newbie Question about addressing impacts References: <5B58696DB20B9140AD20E0685C573A6404FDD6CC@xch-nw-09.nw.nos.boeing.com> <81470BA1-EC87-11D8-B8D4-000A95D1475E@tony.li> <411C7551.4050201@zurich.ibm.com> <39266EE5-ED0B-11D8-B8D4-000A95D1475E@tony.li> <8D217CC4-ED12-11D8-B8D4-000A95D1475E@tony.li> In-Reply-To: <8D217CC4-ED12-11D8-B8D4-000A95D1475E@tony.li> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Li wrote: > > > >>> Years ago, we rejected (a) on the grounds that it would change IPv6 >> >> >> Well, my understanding is that this is still a valid approach to the >> problem, and i didn't get the feeling that we have rejected it (at >> least since i am in this wg), so, may i ask why did you reject this >> approach? > > > > Umm.... as I alluded "we" (not I ;-) rejected this approach because > there are existing > IPv6 host implementations. Those would have to be 'revised' to support > this model. > At the time, the WG felt that this was unacceptable. In my biased opinion, this is why goals 3.2.2 and 3.2.3 in RFC 3582 were written *exactly* as they are. And they are part of the WG consensus, and they do *not* exclude host and router modifications. Brian From owner-multi6@ops.ietf.org Fri Aug 13 09:29: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 JAA14608 for ; Fri, 13 Aug 2004 09:29:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bvc5q-000MoJ-GT for multi6-data@psg.com; Fri, 13 Aug 2004 13:27:38 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bvc5f-000MnL-A9 for multi6@ops.ietf.org; Fri, 13 Aug 2004 13:27:27 +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 i7DDREgB152114; Fri, 13 Aug 2004 13:27: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 i7DDRCcL060906; Fri, 13 Aug 2004 15:27:12 +0200 Received: from zurich.ibm.com (sig-9-145-130-225.de.ibm.com [9.145.130.225]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA35910; Fri, 13 Aug 2004 15:27:08 +0200 Message-ID: <411CC1AB.9040902@zurich.ibm.com> Date: Fri, 13 Aug 2004 15:27:07 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: marcelo bagnulo braun CC: Arifumi Matsumoto , multi6@ops.ietf.org Subject: Re: Newbie Question about addressing impacts References: <5B58696DB20B9140AD20E0685C573A640299305D@xch-nw-09.nw.nos.boeing.com> <411B7E26.2030008@zurich.ibm.com> <1BB1D8B2-ED1B-11D8-9FC6-000D93ACD0FE@it.uc3m.es> In-Reply-To: <1BB1D8B2-ED1B-11D8-9FC6-000D93ACD0FE@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit If I recall correctly, the policy table can list prefixes explicitly in priority order. So for mh, than means that policy can say: if A fails, try B; if B fails, try C. But I may be misremembering 3484, it's been a while... Brian marcelo bagnulo braun wrote: > Hi Brian, Arifumi, > > I am not sure that the policy table falls under this particular > component, since as i see it, the policy table is more related with > locator selection when there are no failures and it is used as a mean to > express administrative prefferences. > Anyway, as i understand it, Arifumi is considering mechanisms to > distribute RFC3484 policy table, so this is not really related to > locator selection, but rather with centralized policy management. > IMHO this will be a requirement, especially as the sites grow bigger, > because manually configuring the policy table of each hosts doesn't > seems a reasonable approach when there is a considerable number of hosts. > Well, in any case, i can see basically two options to provide automatic > configuration of RFC3484 policy table: > - router Advertisement > - dhcp option > > the porblem with RA is that the full policy table has to fit in a single > RA message, since imho the distribution of the policy table should be > atomic (having only part of the policy table configure may cause > undesired behaviour), in addition, RA requires the configuration of the > policy table in at least one router per link, which may be cumbersome > the problem with dhcp is that you need a dhcp server, but it provides > most of the desired features AFAICS > > imho, a policy distribution mechanism will be needed at some moment. > We have made a couple of implementations in linux of the two policy > table distribution mechanisms, one using dhcp and another one using RA, > to see how this work. > If anyone is interested, we can discuss it. > > Regards, marcelo > > El 12/08/2004, a las 16:26, Brian E Carpenter escribió: > >> One of the components we have already identified (see the minutes >> from San Diego) is >> >> Locator selection after a failure has been detected / Choose new >> address pair >> >> RFC 3484 policy distribution might be a possible solution >> for that component. We aren't chartered to do basic design in >> this WG, but it would certainly be good to see proof-of-concept >> for this (and every) component. >> >> Brian >> >> >> Arifumi Matsumoto wrote: >> >>> Oops, I forgot to send CC to multi6. >>> -- >>> Hi marcelo, >>> >>>> Well, even if you do a per host locator selection you can still >>>> manage policy in a centralized fashion, if we define proper >>>> mechanisms to perform policy distribution, for instance a dhcp >>>> option for distributing RFC3484 policy table or something similar. >>>> However, i don't know how you can enforce policy in a centralized >>>> manner when locator selection is performed by the end hosts. >>> >>> I believe that such a mechanism for policy distribution >>> is really important. By making use of the existing RFC3484 >>> framework, IMHO we can develop much manageable multi-home >>> environment in a simple and easy manner. >>> Now I'm working on this mechanism to publish a new I-D. >>> But I'm not sure such kind of topic is appropriate for >>> this WG or not. I believe this part of the technology should >>> be necessary for some of the proposals discussed here, though. >>> -- >>> Arifumi Matsumoto >>> Ubiquitous Computing Project >>> NTT Information Sharing Platform Laboratories >>> E-mail: arifumi@nttv6.net >> >> > > > From owner-multi6@ops.ietf.org Fri Aug 13 10:11:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17951 for ; Fri, 13 Aug 2004 10:11:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bvclf-0003LK-Vq for multi6-data@psg.com; Fri, 13 Aug 2004 14:10:51 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvclV-0003Kh-7F for multi6@ops.ietf.org; Fri, 13 Aug 2004 14:10:41 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id B62054F32; Fri, 13 Aug 2004 10:10:40 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 10:10:40 -0400 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: Newbie Question about addressing impacts Date: Fri, 13 Aug 2004 10:11:07 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0704523F@tayexc13.americas.cpqcorp.net> Thread-Topic: Newbie Question about addressing impacts Thread-Index: AcSBDTcilpVMgo7BRoCg6LO/PywV2AAMiFvA From: "Bound, Jim" To: "Brian E Carpenter" , "Multi6" X-OriginalArrivalTime: 13 Aug 2004 14:10:40.0658 (UTC) FILETIME=[507E1720:01C4813F] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I agree with Brian on this point strongly. /jim=20 > -----Original Message----- > From: owner-multi6@ops.ietf.org=20 > [mailto:owner-multi6@ops.ietf.org] On Behalf Of Brian E Carpenter > Sent: Friday, August 13, 2004 4:01 AM > To: Multi6 > Subject: Re: Newbie Question about addressing impacts >=20 > Tony Li wrote: > >=20 > > On Aug 12, 2004, at 6:31 AM, Fleischman, Eric wrote: > >=20 > >> This is an interesting idea. However, if we embed proxy functions=20 > >> into border routers it would potentially add overhead (as well as=20 > >> latency) and make them harder to manage. Specifically, the=20 > number of=20 > >> border routers is likely to increase as network perimeters become=20 > >> more porous. Thus, this idea carries with it the need to=20 > ensure that=20 > >> these distributed routers can be configured with=20 > consistent policies. > >> > >> Simple is good in operations. > >> > >=20 > >=20 > > Well, then the other architectural alternative that I can see is to=20 > > embed NAT-like functionality in all of the hosts. > >=20 > > I find this scarier. >=20 > Chair hat off: >=20 > I repeat my comment from when I first saw Mike O'Dell's original 8+8 > proposal: "It's architected NAT." I think anything that=20 > massages locators, whether it's in the host stack or in a=20 > proxy, comes down to architected NAT. Which means there is=20 > going to be state, so that the massage can be reversed, so=20 > that the ULP always sees the same e2e identifier. It's a=20 > design choice whether that state is in hosts, proxies, or both. >=20 > Actually, we're kidding ourselves if we don't admit that this=20 > is what we are going to end up doing. >=20 > Chair hat on: >=20 > The design team has been asked to develop one specific=20 > approach to this, namely the IP wedge layer approach, because=20 > that is where the proposals and interest in the WG seem to be=20 > concentrated. >=20 > Brian >=20 >=20 >=20 From owner-multi6@ops.ietf.org Fri Aug 13 10:12: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 KAA18076 for ; Fri, 13 Aug 2004 10:12:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bvcmq-0003Vk-0V for multi6-data@psg.com; Fri, 13 Aug 2004 14:12:04 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvcmX-0003UA-3B for multi6@ops.ietf.org; Fri, 13 Aug 2004 14:11:45 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id BEE396A10; Fri, 13 Aug 2004 10:11:44 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 10:11:44 -0400 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: Newbie Question about addressing impacts Date: Fri, 13 Aug 2004 10:12:11 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07045240@tayexc13.americas.cpqcorp.net> Thread-Topic: Newbie Question about addressing impacts Thread-Index: AcSBGOkNOYBEdpyQR4mLbXErnHMOHQAJoksQ From: "Bound, Jim" To: "Tony Li" , "Brian E Carpenter" Cc: "Multi6" X-OriginalArrivalTime: 13 Aug 2004 14:11:44.0636 (UTC) FILETIME=[76A05BC0:01C4813F] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable And I think it wise to table the complete solution space to define and get something working now. =20 /jim > -----Original Message----- > From: owner-multi6@ops.ietf.org=20 > [mailto:owner-multi6@ops.ietf.org] On Behalf Of Tony Li > Sent: Friday, August 13, 2004 5:29 AM > To: Brian E Carpenter > Cc: Multi6 > Subject: Re: Newbie Question about addressing impacts >=20 > > I repeat my comment from when I first saw Mike O'Dell's original 8+8 > > proposal: "It's architected NAT." I think anything that massages=20 > > locators, whether it's in the host stack or in a proxy,=20 > comes down to=20 > > architected NAT. Which means there is going to be state, so=20 > that the=20 > > massage can be reversed, so that the ULP always sees the same e2e=20 > > identifier. It's a design choice whether that state is in hosts,=20 > > proxies, or both. > > > > Actually, we're kidding ourselves if we don't admit that=20 > this is what=20 > > we are going to end up doing. > > >=20 >=20 > I think that it is vitally important that we all understand=20 > this and how we got here. If we want a host to respond=20 > flexibly to multiple addresses, then either (a) the protocol=20 > stack needs to know about the various addresses and can swap=20 > between them on the fly, OR > (b) something NATty outside of the protocol stack has to=20 > "fool" the protocol stack into responding consistently. >=20 > Years ago, we rejected (a) on the grounds that it would change IPv6. > Folks who want to reject (b) now need to understand that they=20 > will be rejecting the entire solution space... >=20 > Tony >=20 >=20 >=20 From owner-multi6@ops.ietf.org Fri Aug 13 10:13: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 KAA18205 for ; Fri, 13 Aug 2004 10:13:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bvco5-0003gn-1O for multi6-data@psg.com; Fri, 13 Aug 2004 14:13:21 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bvcnu-0003eO-5u for multi6@ops.ietf.org; Fri, 13 Aug 2004 14:13:10 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id C82F06209; Fri, 13 Aug 2004 10:13:09 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 10:13:09 -0400 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Newbie Question about addressing impacts Date: Fri, 13 Aug 2004 10:13:36 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07045242@tayexc13.americas.cpqcorp.net> Thread-Topic: Newbie Question about addressing impacts Thread-Index: AcSBIymrpGoQ3QALSn+MD2W7/D7hdwAHHSiA From: "Bound, Jim" To: "marcelo bagnulo braun" , "Tony Li" Cc: "Multi6" , "Brian E Carpenter" X-OriginalArrivalTime: 13 Aug 2004 14:13:09.0719 (UTC) FILETIME=[A956FE70:01C4813F] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Not really there are approaches that do not require modifications and if = do modify then the positions against SCTP because of modification are = invalid and bogus. /jim=20 > -----Original Message----- > From: owner-multi6@ops.ietf.org=20 > [mailto:owner-multi6@ops.ietf.org] On Behalf Of marcelo bagnulo braun > Sent: Friday, August 13, 2004 6:45 AM > To: Tony Li > Cc: Multi6; Brian E Carpenter > Subject: Re: Newbie Question about addressing impacts >=20 >=20 > El 13/08/2004, a las 12:21, Tony Li escribi=F3: >=20 > > > > > > > >>> Years ago, we rejected (a) on the grounds that it would=20 > change IPv6 > >> > >> Well, my understanding is that this is still a valid=20 > approach to the=20 > >> problem, and i didn't get the feeling that we have rejected it (at=20 > >> least since i am in this wg), so, may i ask why did you=20 > reject this=20 > >> approach? > > > > > > Umm.... as I alluded "we" (not I ;-) rejected this approach because=20 > > there are existing > > IPv6 host implementations. Those would have to be 'revised' to=20 > > support this model. > > At the time, the WG felt that this was unacceptable. > > >=20 > Ok. But currently, i think that it seems clear that any of=20 > the both approaches will require modifications in both ends=20 > of the communication. > I mean, any solution for preserving established sessions will=20 > impose modifications in both ends, mainly because security=20 > issues, so i guess that from this p.o.v. both approaches are=20 > equally acceptable, right? >=20 > regards, marcelo >=20 > > Tony > > >=20 >=20 >=20 From owner-multi6@ops.ietf.org Fri Aug 13 11:21: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 LAA22398 for ; Fri, 13 Aug 2004 11:21:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bvdqk-000DH0-P4 for multi6-data@psg.com; Fri, 13 Aug 2004 15:20:10 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvdqZ-000DEQ-UT for multi6@ops.ietf.org; Fri, 13 Aug 2004 15:20:00 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D1043872DF; Fri, 13 Aug 2004 11:19:58 -0400 (EDT) To: multi6@ops.ietf.org Subject: Re: Newbie Question about addressing impacts Cc: jnc@mercury.lcs.mit.edu Message-Id: <20040813151958.D1043872DF@mercury.lcs.mit.edu> Date: Fri, 13 Aug 2004 11:19:58 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Brian E Carpenter > I repeat my comment from when I first saw Mike O'Dell's original 8+8 > proposal: "It's architected NAT." I think anything that massages > locators, whether it's in the host stack or in a proxy, comes down to > architected NAT. Which means there is going to be state, so that th > massage can be reversed, so that the ULP always sees the same e2e > identifier. Ah, no. If my recall of 8+8 is correct, *only* the lower 8 bytes was to be used as the end-end identifier. The high-order part (massaged to contain the appropriate topology location information) was to be ignored for end-end identification purposes. Obviously the binding between the two needed to be protected, to prevent e.g. connection hijacking (unless end-end authentication were used at all times). This was one of the big problems with 8+8, where the entity which handled the "locator" part was *not* the end-end entity. Therefore, even had the binding been secured, the end entity would have had to trust another entity to securely manage the binding. In fact, with all schemes which propose to move the management of the binding to some entity other than the end-end entity (i.e. if you propose to *not* have the end-end entity know its locators, and manage and secure the bindings), you have the same problem. Either i) you have to use end-end authentication at all times (i.e. the identity-location binding doesn't need to be secured), or ii) the end-end entity has to trust some other entity to manage and secure the binding. Actually, though, now that I think about it, you always need a minimal amount of security on the binding, other you can have a DoS attack - some third party can change the binding, causing the connection to fail. So option i) is not in fact really viable. So that brings up back to the basic architectual point: if you separate location and identity, either the end-end entity named by the identity has to manage the binding (and know something of locators), or it has to trust some other entity to secure its bindings. Noel From owner-multi6@ops.ietf.org Fri Aug 13 12: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 MAA26700 for ; Fri, 13 Aug 2004 12:26:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bveqs-000NU9-C2 for multi6-data@psg.com; Fri, 13 Aug 2004 16:24:22 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BveqB-000NO7-Jh for multi6@ops.ietf.org; Fri, 13 Aug 2004 16:23:39 +0000 Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA21678; Fri, 13 Aug 2004 09:23:38 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i7DGNcE10060; Fri, 13 Aug 2004 09:23:38 -0700 (PDT) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 09:23:37 -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: Newbie Question about addressing impacts Date: Fri, 13 Aug 2004 09:23:37 -0700 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDD6DA@xch-nw-09.nw.nos.boeing.com> Thread-Topic: Newbie Question about addressing impacts Thread-Index: AcSBDZguTdkpE+lIRa2C4XvBOS/wwgAP6AOA From: "Fleischman, Eric" To: "Brian E Carpenter" , "Multi6" X-OriginalArrivalTime: 13 Aug 2004 16:23:37.0829 (UTC) FILETIME=[E341C950:01C48151] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Friends, I am struggling with these issues and don't feel that I have a solution. = The view from my knot hole is that very large corporate networks (i.e., = Fortune 100, governments) are likely to refuse to renumber or support = multiple internal addresses due to cost reasons (e.g., cost of = renumbering itself, explosion of routing table entries for IGP, DNS = issues, directory issues, DHCP confusion, QoS confusion (e.g., for = policing and marking), etc.). Thus, huge corporations are likely to = demand that we own our own addresses and that ISPs would therefore have = less aggregation as a result. Even should "the system" not permit this, = it shouldn't be hard to find ISPs willing to support us in the manner we = require for "the right price." Thus, it is inevitable (in my own mind) = that this is what the Fortune 100 and governments will do and the IETF = really has no say in the matter -- unless it can come up with a = transparent approach to remove the penalty of renumbering from our = operations. That is, should the penalty of readdressing be removed, then = we wouldn't be compelled to "do our own thing" in this matter. On the other hand, such behavior is unacceptable from a "Internet = citizenship" perspective and does not address the similar business = issues that moderate size corporations (e.g., 100,000 employees) have, = which would influence them to behave in a manner similar to the Fortune = 100. But if moderate size corporations do this, then why not smallish = corporations (e.g., 20,000 employees) act similarly? After all, they = have similar "bottom line" concerns, which are certainly as valid as = those of the Fortune 100. And if they behave similarly, then how about = small companies? And before you know it, aggregation is out the window, = and that is A Very Bad Thing. So we come up with Tony's solution to make NAT- or proxy-like additions = to the IP architecture to account for this in order to localize the = effects of renumbering to the perimeters, and thus reduce its pain. As = Tony implied, it is much easier to do this at routers than the order of = magnitude more numerous computers. However, such "fatter IP layer" = approaches add latencies and impact performance, often in subtle ways.=20 In my own mind, this topic is indirectly related to the goal of = converging voice and video upon IP. I personally have concluded that QoS = doesn't work as advertised as a convergence mechanism such that = convergence can best occur in real life only via over-provisioning. I = realize this is an unpopular conclusion, because it explicitly claims = that the IP layer can only get so fat, after which it becomes = ineffectual. I fear that multihoming will fatten the IP Layer in ways = that we do not fully understand now. The degree of fatness of the IP = Layer is something that must concern all of us... I am reminded of Steve = Deering's many IETF plenary speeches back in the late 90s. This topic is = a very weighty one. If Tony Li is correct (and I explicitly trust his judgment), then the = decision may be between keeping addresses constant and thus harming = routing aggregation versus renumbering and thus fattening the IP Layer. = Are there other alternatives? What do you think? --Eric -----Original Message----- From: Brian E Carpenter [mailto:brc@zurich.ibm.com] Sent: Friday, August 13, 2004 1:01 AM To: Multi6 Subject: Re: Newbie Question about addressing impacts Tony Li wrote: >=20 > On Aug 12, 2004, at 6:31 AM, Fleischman, Eric wrote: >=20 >> This is an interesting idea. However, if we embed proxy functions = into=20 >> border routers it would potentially add overhead (as well as latency) = >> and make them harder to manage. Specifically, the number of border=20 >> routers is likely to increase as network perimeters become more=20 >> porous. Thus, this idea carries with it the need to ensure that these = >> distributed routers can be configured with consistent policies. >> >> Simple is good in operations. >> >=20 >=20 > Well, then the other architectural alternative that I can see is to=20 > embed NAT-like functionality in all of the hosts. >=20 > I find this scarier. Chair hat off: I repeat my comment from when I first saw Mike O'Dell's original 8+8 proposal: "It's architected NAT." I think anything that massages = locators, whether it's in the host stack or in a proxy, comes down to architected NAT. Which means there is going to be state, so that the massage can be reversed, so that the ULP always sees the same e2e identifier. It's a design choice whether that state is in hosts, proxies, or both. Actually, we're kidding ourselves if we don't admit that this is what we are going to end up doing. Chair hat on: The design team has been asked to develop one specific approach to this, namely the IP wedge layer approach, because that is where the proposals and interest in the WG seem to be concentrated. Brian From owner-multi6@ops.ietf.org Fri Aug 13 13:10: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 NAA29585 for ; Fri, 13 Aug 2004 13:10:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvfYN-0004gq-By for multi6-data@psg.com; Fri, 13 Aug 2004 17:09:19 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvfYC-0004dh-45 for multi6@ops.ietf.org; Fri, 13 Aug 2004 17:09: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 i7DHBLMW040325; Fri, 13 Aug 2004 19:11:21 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDD6DA@xch-nw-09.nw.nos.boeing.com> References: <5B58696DB20B9140AD20E0685C573A6404FDD6DA@xch-nw-09.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7AEA4E96-ED4B-11D8-8309-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Newbie Question about addressing impacts Date: Fri, 13 Aug 2004 19:09:04 +0200 To: "Fleischman, Eric" X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 13-aug-04, at 18:23, Fleischman, Eric wrote: > very large corporate networks (i.e., Fortune 100, governments) are > likely to refuse to renumber or support multiple internal addresses > due to cost reasons So basically what you're saying is that using ISP-derived addresses is unacceptable for the largest organizations regardless of multihoming? Are the costs of renumbering an inherent property or are there things we can do to make this easier and cheaper? (I've done some experimenting with stateless address configuration renumbering, and this works extremely well. However, the routers and the DNS are more difficult. But the real problem are IP address based access restrictions. These are evil.) Also, a very important issue is whether such a large organization would use a single address block, or a number of address blocks. In the former case the organization will receive packets for location A in location B, and thus have to arrange transportation of these packets themselves, which is more expensive than having ISPs deliver it to the right location immediately. I think we can consider giving the n largest organizations in the world their own block (for reasonable values of n), but having n organizations introduce m entries in the routing system would be adding insult to injury and isn't going to fly. From owner-multi6@ops.ietf.org Sat Aug 14 21:11: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 VAA10955 for ; Sat, 14 Aug 2004 21:11:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bw9Tw-000Pjk-7V for multi6-data@psg.com; Sun, 15 Aug 2004 01:06:44 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bw9Tl-000Pii-J4 for multi6@ops.ietf.org; Sun, 15 Aug 2004 01:06:33 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Sat, 14 Aug 2004 18:09:02 -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); Sat, 14 Aug 2004 18:09:14 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Aug 2004 18:05:18 -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); Sat, 14 Aug 2004 18:05:45 -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: Newbie Question about addressing impacts Date: Sat, 14 Aug 2004 18:06:38 -0700 Message-ID: Thread-Topic: Newbie Question about addressing impacts thread-index: AcSBDZguTdkpE+lIRa2C4XvBOS/wwgAP6AOAAEWDT7A= From: "Christian Huitema" To: "Fleischman, Eric" , "Brian E Carpenter" , "Multi6" X-OriginalArrivalTime: 15 Aug 2004 01:05:45.0502 (UTC) FILETIME=[FE6B13E0:01C48263] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > On the other hand, such behavior is unacceptable from a "Internet > citizenship" perspective and does not address the similar business issues > that moderate size corporations (e.g., 100,000 employees) have, which > would influence them to behave in a manner similar to the Fortune 100. But > if moderate size corporations do this, then why not smallish corporations > (e.g., 20,000 employees) act similarly? After all, they have similar > "bottom line" concerns, which are certainly as valid as those of the > Fortune 100. And if they behave similarly, then how about small companies? > And before you know it, aggregation is out the window, and that is A Very > Bad Thing. Is it, really? The IPv4 routing tables currently have about 100,000 entries, and the sky is not falling. So we should assume that 100,000 entries is OK now, in 2004. If I remember correctly, the equivalent limit was about 10,000 entries in 2004, ten times less ten years ago. We might imagine that the limit will be ten times higher ten years from now. The entire earth population is not expected to reach 10 billion people any time soon, which means there cannot possibly be more than 100,000 companies with 100,000 employees world wide, or a million companies with 10,000 employees. This pretty much implies that we could flat-route all the companies with 100,000 employees now, and all of those with 10,000 employees ten years from now... -- Christian Huitema From owner-multi6@ops.ietf.org Sat Aug 14 23:28: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 XAA15213 for ; Sat, 14 Aug 2004 23:28:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwBf4-000FIO-1e for multi6-data@psg.com; Sun, 15 Aug 2004 03:26:22 +0000 Received: from [216.148.227.85] (helo=rwcrmhc12.comcast.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwBes-000FHJ-Pd for multi6@ops.ietf.org; Sun, 15 Aug 2004 03:26:10 +0000 Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (rwcrmhc12) with SMTP id <2004081503260901400r5mohe> (Authid: li.tony); Sun, 15 Aug 2004 03:26:10 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Fleischman, Eric" , "Brian E Carpenter" , "Multi6" From: Tony Li Subject: Re: Newbie Question about addressing impacts Date: Sat, 14 Aug 2004 20:26:08 -0700 To: "Christian Huitema" X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Is it, really? The IPv4 routing tables currently have about 100,000 > entries, and the sky is not falling. So we should assume that 100,000 > entries is OK now, in 2004. If I remember correctly, the equivalent > limit was about 10,000 entries in 2004, ten times less ten years ago. > We > might imagine that the limit will be ten times higher ten years from > now. > > The entire earth population is not expected to reach 10 billion people > any time soon, which means there cannot possibly be more than 100,000 > companies with 100,000 employees world wide, or a million companies > with > 10,000 employees. This pretty much implies that we could flat-route all > the companies with 100,000 employees now, and all of those with 10,000 > employees ten years from now... > You're absolutely right Christian, and since memory is cheap, we should seriously consider ditching this IP business. Let's just bridge everything together. In ten years, we'll be able to support 10 billion MAC addresses in our bridging tables and we'll avoid all of these routing issues. In case folks have not noticed, thanks to certain people carrying other stuff in inter-domain protocols, the minimal requirement today is to carry 1e6 routes already. This number is driven by the Internet routing table size, as people want to be able to support carrier-of-carrier VPNs, resulting in VPNs that are part of the default-free zone (DFZ). If we grow the Internet routing table to say 1e6 routes, then the VPN demands will be something like 1e7 or 1e8. This will be yet another tax on the carriers and will get passed on to us, the consumers. I think that it is in our common interest to keep the routing subsystem efficient, stable, and cheap. Saying that we don't have a problem today because the sky is not falling is like saying that nothing is wrong because we're not dead yet, so go right ahead, have another . Those of us who would like to live a wee bit longer will excercise a modicum of moderation in how we treat the common infrastructure. Regards, Tony From owner-multi6@ops.ietf.org Sun Aug 15 00:02: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 AAA16510 for ; Sun, 15 Aug 2004 00:02:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwCC8-000IvO-M3 for multi6-data@psg.com; Sun, 15 Aug 2004 04:00:32 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwCBy-000Itl-14 for multi6@ops.ietf.org; Sun, 15 Aug 2004 04:00:22 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 392013B0 for ; Sun, 15 Aug 2004 00:00:21 -0400 (EDT) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 15 Aug 2004 00:00:21 -0400 Message-Id: <20040815040021.392013B0@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 24.32% | 9 | 34.07% | 52348 | brc@zurich.ibm.com 16.22% | 6 | 16.83% | 25854 | marcelo@it.uc3m.es 16.22% | 6 | 11.92% | 18307 | tony.li@tony.li 13.51% | 5 | 11.66% | 17910 | jim.bound@hp.com 8.11% | 3 | 9.62% | 14787 | eric.fleischman@boeing.com 5.41% | 2 | 3.97% | 6103 | iljitsch@muada.com 2.70% | 1 | 2.56% | 3937 | huitema@windows.microsoft.com 2.70% | 1 | 2.30% | 3528 | jnc@mercury.lcs.mit.edu 2.70% | 1 | 2.10% | 3221 | pekkas@netcore.fi 2.70% | 1 | 1.84% | 2821 | a@arifumi.net 2.70% | 1 | 1.61% | 2477 | sra@hactrn.net 2.70% | 1 | 1.53% | 2347 | dhc@dcrocker.net --------+------+--------+----------+------------------------ 100.00% | 37 |100.00% | 153640 | 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 Aug 15 02:26: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 CAA07138 for ; Sun, 15 Aug 2004 02:26:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwERn-0008Kf-Vm for multi6-data@psg.com; Sun, 15 Aug 2004 06:24:51 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwERd-0008KE-DS for multi6@ops.ietf.org; Sun, 15 Aug 2004 06:24:41 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Sat, 14 Aug 2004 23:27:58 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Aug 2004 23:23:58 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Aug 2004 23:23:49 -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); Sat, 14 Aug 2004 23:23: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: Newbie Question about addressing impacts Date: Sat, 14 Aug 2004 23:23:54 -0700 Message-ID: Thread-Topic: Newbie Question about addressing impacts thread-index: AcSCd4Ft5Cg4vwSiSbGr4mqTl3DKOAAF3FJA From: "Christian Huitema" To: "Tony Li" Cc: "Fleischman, Eric" , "Brian E Carpenter" , "Multi6" X-OriginalArrivalTime: 15 Aug 2004 06:23:12.0308 (UTC) FILETIME=[57330740:01C48290] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > If we grow the Internet routing table to say 1e6 routes, then the VPN > demands will be something like 1e7 or 1e8. This will be yet another > tax on the carriers and will get passed on to us, the consumers. I am sorry, but I don't get the VPN point. The number of VPN is proportional to the number of sites willing to establish VPN connections, and not linked to the availability of global addresses for these sites. Eric is making a basic point of economics. Large companies will want to get a global address, effectively shifting network management cost from their IT department to the ISP community. A number of folks in this group believe this is a bad idea, and are essentially trying to write in the standards that such cost shifting should be illegal. I personally don't think it should be illegal, although I am ready to admit that it should be expensive, as in "no free lunch". Your mention that routers commonly support 1E6 routing entries seems to indicate that some amount of "cost shifting" is indeed feasible. By the way, routing in a flat space of 10 billion entries is also feasible, using distributed hash tables. However, with the current algorithms, the average path length will be markedly larger than the shortest path. -- Christian Huitema From owner-multi6@ops.ietf.org Sun Aug 15 04:22: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 EAA12206 for ; Sun, 15 Aug 2004 04:22:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwGF4-000L59-Vy for multi6-data@psg.com; Sun, 15 Aug 2004 08:19:50 +0000 Received: from [204.127.198.35] (helo=rwcrmhc11.comcast.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwGEe-000L1E-4e for multi6@ops.ietf.org; Sun, 15 Aug 2004 08:19:24 +0000 Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (rwcrmhc11) with SMTP id <200408150819190130013gdhe> (Authid: li.tony); Sun, 15 Aug 2004 08:19:23 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Fleischman, Eric" , "Brian E Carpenter" , "Multi6" From: Tony Li Subject: Re: Newbie Question about addressing impacts Date: Sun, 15 Aug 2004 01:19:18 -0700 To: "Christian Huitema" X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I am sorry, but I don't get the VPN point. The number of VPN is > proportional to the number of sites willing to establish VPN > connections, and not linked to the availability of global addresses for > these sites. If PI addresses are made widely available, then the routing table will grow. As the routing table grows, each carrier must grow its tables to support default-free routing. To be able to provide VPN services, the carrier must be able to support all of the routes that his customers wish to support. Since several of these customers could reasonably be Tier 1 backbones, they will be carrying the full table. Thus, there is an amplification factor (currently about 10x) of the size of the table vs. what routers have to hold. If that grows (as seems likely as the size of the DFZ grows), then the amplification times the natural growth of the table will continue to push technology. > > Eric is making a basic point of economics. Large companies will want to > get a global address, effectively shifting network management cost from > their IT department to the ISP community. A number of folks in this > group believe this is a bad idea, and are essentially trying to write > in > the standards that such cost shifting should be illegal. I personally > don't think it should be illegal, although I am ready to admit that it > should be expensive, as in "no free lunch". Well, I don't think that "illegal" is possible, given that we are not a legislative entity. I don't think that anyone would object to a market for routing table entries, but it has yet to appear. > > Your mention that routers commonly support 1E6 routing entries seems to > indicate that some amount of "cost shifting" is indeed feasible. No, I don't think that's sufficient. We have yet to see any type of cost shifting occur. For that to happen, we would have to have a market and the fact that it does NOT exist means that we don't have a mechanism to work with. Yes, this is an economic, not technical issue. However, we as technologists have the responsibility to raise the awareness of this and to promote prefix conservation. Tony From owner-multi6@ops.ietf.org Sun Aug 15 04: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 EAA13207 for ; Sun, 15 Aug 2004 04:59:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwGq5-000P3L-IA for multi6-data@psg.com; Sun, 15 Aug 2004 08:58:05 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwGpu-000P2E-Ed for multi6@ops.ietf.org; Sun, 15 Aug 2004 08:57:54 +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 i7F906MW054399; Sun, 15 Aug 2004 11:00:09 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2FC84E82-EE99-11D8-8309-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Newbie Question about addressing impacts Date: Sun, 15 Aug 2004 10:57:50 +0200 To: "Christian Huitema" X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 15-aug-04, at 3:06, Christian Huitema wrote: > The IPv4 routing tables currently have about 100,000 entries, and the > sky is not falling. I'm not so sure. I have several customers who are experiencing random BGP instabilities from time to time. I haven't figured this out completely yet, but there seems to be a disconnect between the number of BGP routes and the amount of processing they require (MD5...) and the CPU speed in the routers. > The entire earth population is not expected to reach 10 billion people > any time soon, which means there cannot possibly be more than 100,000 > companies with 100,000 employees world wide, or a million companies > with > 10,000 employees. This pretty much implies that we could flat-route all > the companies with 100,000 employees now, and all of those with 10,000 > employees ten years from now... We can argue whether this is desirable, but a more fundamental objection is that this implicitly assumes one route per company. In other words: companies must transport internet traffic between different sites over their own infrastructure. That's not very cost effective these days. From owner-multi6@ops.ietf.org Sun Aug 15 09:06: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 JAA23460 for ; Sun, 15 Aug 2004 09:06:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwKf5-0001Rp-AF for multi6-data@psg.com; Sun, 15 Aug 2004 13:02:59 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwKeu-0001Qs-H4 for multi6@ops.ietf.org; Sun, 15 Aug 2004 13:02:48 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 3BEAC4F73; Sun, 15 Aug 2004 09:02:46 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 15 Aug 2004 09:02:46 -0400 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: Newbie Question about addressing impacts Date: Sun, 15 Aug 2004 09:03:15 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0704532F@tayexc13.americas.cpqcorp.net> Thread-Topic: Newbie Question about addressing impacts Thread-Index: AcSCoY0A6gOendfOTGawDhqBi3VwVwAJosWA From: "Bound, Jim" To: "Tony Li" , "Christian Huitema" Cc: "Fleischman, Eric" , "Brian E Carpenter" , "Multi6" X-OriginalArrivalTime: 15 Aug 2004 13:02:46.0071 (UTC) FILETIME=[28ACF470:01C482C8] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Prefix conservation or any type of forced VPN within the answer with NAT is immoral view as technologist. /jim=20 > -----Original Message----- > From: owner-multi6@ops.ietf.org=20 > [mailto:owner-multi6@ops.ietf.org] On Behalf Of Tony Li > Sent: Sunday, August 15, 2004 4:19 AM > To: Christian Huitema > Cc: Fleischman, Eric; Brian E Carpenter; Multi6 > Subject: Re: Newbie Question about addressing impacts >=20 > > I am sorry, but I don't get the VPN point. The number of VPN is=20 > > proportional to the number of sites willing to establish VPN=20 > > connections, and not linked to the availability of global addresses=20 > > for these sites. >=20 >=20 > If PI addresses are made widely available, then the routing=20 > table will grow. As the routing table grows, each carrier=20 > must grow its tables to support default-free routing. To be=20 > able to provide VPN services, the carrier must be able to=20 > support all of the routes that his customers wish to support.=20 > Since several of these customers could reasonably be Tier 1=20 > backbones, they will be carrying the full table. Thus, there=20 > is an amplification factor (currently about 10x) of the size=20 > of the table vs. what routers have to hold. If that grows=20 > (as seems likely as the size of the DFZ grows), then the=20 > amplification times the natural growth of the table will=20 > continue to push technology. >=20 > > > > Eric is making a basic point of economics. Large companies=20 > will want=20 > > to get a global address, effectively shifting network=20 > management cost=20 > > from their IT department to the ISP community. A number of folks in=20 > > this group believe this is a bad idea, and are essentially=20 > trying to=20 > > write in the standards that such cost shifting should be illegal. I=20 > > personally don't think it should be illegal, although I am ready to=20 > > admit that it should be expensive, as in "no free lunch". >=20 >=20 > Well, I don't think that "illegal" is possible, given that we=20 > are not a legislative entity. I don't think that anyone=20 > would object to a market for routing table entries, but it=20 > has yet to appear. >=20 > > > > Your mention that routers commonly support 1E6 routing=20 > entries seems=20 > > to indicate that some amount of "cost shifting" is indeed feasible. >=20 >=20 > No, I don't think that's sufficient. We have yet to see any=20 > type of cost shifting occur. For that to happen, we would=20 > have to have a market and the fact that it does NOT exist=20 > means that we don't have a mechanism to work with. Yes, this=20 > is an economic, not technical issue. However, we as=20 > technologists have the responsibility to raise the awareness=20 > of this and to promote prefix conservation. >=20 >=20 > Tony >=20 >=20 >=20 From owner-multi6@ops.ietf.org Mon Aug 16 03:42: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 DAA14719 for ; Mon, 16 Aug 2004 03:42:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bwc5t-000PDt-1i for multi6-data@psg.com; Mon, 16 Aug 2004 07:39:49 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bwc5J-000P9n-IL for multi6@ops.ietf.org; Mon, 16 Aug 2004 07:39:13 +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 i7G7dCGP054848 for ; Mon, 16 Aug 2004 07:39:12 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 i7G7dBmd211908 for ; Mon, 16 Aug 2004 09:39:12 +0200 Received: from zurich.ibm.com (sig-9-145-242-213.de.ibm.com [9.145.242.213]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA80494 for ; Mon, 16 Aug 2004 09:39:09 +0200 Message-ID: <4120649C.8090009@zurich.ibm.com> Date: Mon, 16 Aug 2004 09:39:08 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: Newbie Question about addressing impacts References: <20040813151958.D1043872DF@mercury.lcs.mit.edu> In-Reply-To: <20040813151958.D1043872DF@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I don't feel this thread is helping us... old arguments, which we have set aside in order to make some progress. Certainly, when we reach the end of our present exercise (i.e. developing the wedge layer solution to the point where a real proof of concept becomes possible, and we can suggest a concrete re-chartering to the IESG) we will need to confront the proposed solution with these issues. But that is some months away. Can we let the design team proceed in peace? Brian WG co-chair From owner-multi6@ops.ietf.org Mon Aug 16 04:16: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 EAA16340 for ; Mon, 16 Aug 2004 04:16:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwceK-0003nC-Ma for multi6-data@psg.com; Mon, 16 Aug 2004 08:15:24 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bwce9-0003m0-Mc for multi6@ops.ietf.org; Mon, 16 Aug 2004 08:15:13 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8FF1A3A08A; Mon, 16 Aug 2004 10:15:12 +0200 (CEST) Received: from [163.117.252.220] (vpn-252-220.uc3m.es [163.117.252.220]) by smtp01.uc3m.es (Postfix) with ESMTP id C4C533A070; Mon, 16 Aug 2004 10:15:11 +0200 (CEST) In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B07045242@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B07045242@tayexc13.americas.cpqcorp.net> 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: "Brian E Carpenter" , "Multi6" , "Tony Li" From: marcelo bagnulo braun Subject: Re: Newbie Question about addressing impacts Date: Mon, 16 Aug 2004 10:17:19 +0200 To: "Bound, Jim" X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Sorry for being imprecise in my comment, i was considering solutions=20 below transport layer here. Regards, marcelo El 13/08/2004, a las 16:13, Bound, Jim escribi=F3: > Not really there are approaches that do not require modifications and=20= > if do modify then the positions against SCTP because of modification=20= > are invalid and bogus. > /jim > >> -----Original Message----- >> From: owner-multi6@ops.ietf.org >> [mailto:owner-multi6@ops.ietf.org] On Behalf Of marcelo bagnulo braun >> Sent: Friday, August 13, 2004 6:45 AM >> To: Tony Li >> Cc: Multi6; Brian E Carpenter >> Subject: Re: Newbie Question about addressing impacts >> >> >> El 13/08/2004, a las 12:21, Tony Li escribi=F3: >> >>> >>> >>> >>>>> Years ago, we rejected (a) on the grounds that it would >> change IPv6 >>>> >>>> Well, my understanding is that this is still a valid >> approach to the >>>> problem, and i didn't get the feeling that we have rejected it (at >>>> least since i am in this wg), so, may i ask why did you >> reject this >>>> approach? >>> >>> >>> Umm.... as I alluded "we" (not I ;-) rejected this approach because >>> there are existing >>> IPv6 host implementations. Those would have to be 'revised' to >>> support this model. >>> At the time, the WG felt that this was unacceptable. >>> >> >> Ok. But currently, i think that it seems clear that any of >> the both approaches will require modifications in both ends >> of the communication. >> I mean, any solution for preserving established sessions will >> impose modifications in both ends, mainly because security >> issues, so i guess that from this p.o.v. both approaches are >> equally acceptable, right? >> >> regards, marcelo >> >>> Tony >>> >> >> >> > From owner-multi6@ops.ietf.org Wed Aug 18 13:12: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 NAA22836 for ; Wed, 18 Aug 2004 13:12:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxTwt-0001TP-KG for multi6-data@psg.com; Wed, 18 Aug 2004 17:10:07 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxTwi-0001PX-Rr for multi6@ops.ietf.org; Wed, 18 Aug 2004 17:09:56 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7IH9sj23244; Wed, 18 Aug 2004 10:09:54 -0700 Date: Wed, 18 Aug 2004 10:09:49 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <171532359.20040818100949@brandenburg.com> To: Brian E Carpenter CC: multi6@ops.ietf.org Subject: Re: TASL In-Reply-To: <411747B0.10300@zurich.ibm.com> References: <41126FBB.90407@zurich.ibm.com> <213168238.20040807165710@brandenburg.com> <411747B0.10300@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, BEC> Seriously, there is obviously a very close relationship (the actual BEC> protocol exchanges would be like those in MAST and NOID, so I didn't BEC> spell them out). But when I re-read MAST I don't see it clearly stated that BEC> a separate, reliable, and secure transport connection is used to carry the separate: yes. reliable: the spec calls for retransmission with exponential backoff. secure: the current spec calls for a random string, to protect against obvious within-session spoofing. doing more than this requires carefully deciding among tradeoffs for cost and benefit. TLS is an easy, reasonable choice, but the overhead of a tcp connection gets a little scary when the scaling effects of having every host-pair do this is considered. BEC> exchanges - that is suggested as an option at the end of the MAST security BEC> considerations, but it is basic to TASL. And I don't see any need to use BEC> XMPP as you suggest in MAST. So I'd argue it's a simpler approach, but BEC> clearly closely related. The question is whether there is need for a dynamic rendezvous service. It is offered as an adjunct, not core, capability in MAST, in order to support situations with mobile servers. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-multi6@ops.ietf.org Thu Aug 19 02:37: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 CAA05513 for ; Thu, 19 Aug 2004 02:37:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxgWL-000OZY-Vr for multi6-data@psg.com; Thu, 19 Aug 2004 06:35:33 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxgWA-000OXc-QL for multi6@ops.ietf.org; Thu, 19 Aug 2004 06:35:23 +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 i7J6ZKGm148016 for ; Thu, 19 Aug 2004 06:35: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 i7J6ZKdo062250 for ; Thu, 19 Aug 2004 08:35:20 +0200 Received: from zurich.ibm.com (sig-9-146-220-166.de.ibm.com [9.146.220.166]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA20366 for ; Thu, 19 Aug 2004 08:35:19 +0200 Message-ID: <41238E5A.4040307@zurich.ibm.com> Date: Wed, 18 Aug 2004 19:14:02 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: I-D ACTION:draft-van-beijnum-multi6-redirection-00.txt References: <200408161918.PAA24594@ietf.org> In-Reply-To: <200408161918.PAA24594@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch, Interesting. If I understand you correctly, you are saying: 1) if a traffic flow is not protected by IPSEC or TLS, it is intrinsically subject to so many attacks that adding multihoming-specific threats makes things no worse; and 2) if the flow is protected, that same protection is sufficient to protect the exchange of multihoming information. Is that a correct summary? If so, I think you are slightly wrong in this: > 3.7 Per-session multihoming signaling > > This document only describes the issues pertaining to a single session > or association. In reality, two endpoints are extremely likely to have a > larger number of sessions between them. I don't think that is generally true. It is true that two endpoints may have more than one session between them, and that is sufficient for your argument. > In this case each session must > receive its own multihoming processing, in order to make sure that a > successful attack against one session doesn't lead to long-time > redirection of additional sessions between the same hosts later. I think the correct statement is that the unprotected sessions (i.e. those without TLS or IPSEC) share fate under attack, since an attack against any one of those sessions can trivially become an attack against all of them. But I don't see why protected sessions can't share state, since they are indeed protected. If an attacker can break that protection for one session, she can presumably break it for all of them, so again they share fate whatever you do. Brian Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Thoughts About Layer 3.5 Redirection Security > Author(s) : I. van Beijnum > Filename : draft-van-beijnum-multi6-redirection-00.txt > Pages : 5 > Date : 2004-8-16 > > The new multi6 design team as of august 2004 is chartered to explore > multihoming by means of a "layer 3.5 wedge" that allows unmodified > applications and transport protocols to become address agile. > > In order to do this, the two hosts involved must communicate certain > parameters. The exact nature of this communication isn't specified at > this time. However, this document discusses certain security issues > pertaining to such communication. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-van-beijnum-multi6-redirection-00.txt From owner-multi6@ops.ietf.org Thu Aug 19 03:55: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 DAA10465 for ; Thu, 19 Aug 2004 03:55:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxhkO-0009u4-Km for multi6-data@psg.com; Thu, 19 Aug 2004 07:54:08 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxhkD-0009q1-Fw for multi6@ops.ietf.org; Thu, 19 Aug 2004 07:53:57 +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 i7J7tuMW095099; Thu, 19 Aug 2004 09:55:57 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <41238E5A.4040307@zurich.ibm.com> References: <200408161918.PAA24594@ietf.org> <41238E5A.4040307@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: I-D ACTION:draft-van-beijnum-multi6-redirection-00.txt Date: Thu, 19 Aug 2004 09:53:41 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 18-aug-04, at 19:14, Brian E Carpenter wrote: > Interesting. If I understand you correctly, you are saying: > 1) if a traffic flow is not protected by IPSEC or TLS, > it is intrinsically subject to so many attacks that > adding multihoming-specific threats makes things no worse; Right. Slightly different of course, but not really worse. > and 2) if the flow is protected, that same protection is > sufficient to protect the exchange of multihoming information. > Is that a correct summary? Yes. > If so, I think you are slightly wrong in this: >> 3.7 Per-session multihoming signaling >> This document only describes the issues pertaining to a single session >> or association. In reality, two endpoints are extremely likely to >> have a >> larger number of sessions between them. > I don't think that is generally true. Send me your endpoints and I will do measurements. :-) > It is true that two endpoints may > have more than one session between them, and that is sufficient > for your argument. Yes. >> In this case each session must >> receive its own multihoming processing, in order to make sure that a >> successful attack against one session doesn't lead to long-time >> redirection of additional sessions between the same hosts later. > I think the correct statement is that the unprotected sessions > (i.e. those without TLS or IPSEC) share fate under attack, > since an attack against any one of those sessions can trivially > become an attack against all of them. But I don't see why protected > sessions can't share state, since they are indeed protected. > If an attacker can break that protection for one session, she can > presumably break it for all of them, so again they share fate > whatever you do. The thing we want to avoid is that an attacker manages to sniff some traffic for a short time, and then gets to redirect not only current sessions, but also new ones set up after the attacker can no longer sniff. (Which would happen if all of this worked per address rather than "per session".) I think it's not only possible to share state between protected sessions, but also between non-protected sessions. This should eliminate much of the overhead of having to work per-session. And the most interesting case would be to share state from protected sessions with unprotected sessions so these are now also better protected (although still vulnerable to regular unprotected IP attacks). Are you sure you don't want to be on the design team list? :-) From owner-multi6@ops.ietf.org Sun Aug 22 00:05: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 AAA20313 for ; Sun, 22 Aug 2004 00:05:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByjX0-000P8F-42 for multi6-data@psg.com; Sun, 22 Aug 2004 04:00:34 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByjWp-000P4E-Dw for multi6@ops.ietf.org; Sun, 22 Aug 2004 04:00:23 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 6A35C603 for ; Sun, 22 Aug 2004 00:00:22 -0400 (EDT) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 22 Aug 2004 00:00:22 -0400 Message-Id: <20040822040022.6A35C603@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.00% | 2 | 19.90% | 7291 | brc@zurich.ibm.com 20.00% | 2 | 19.57% | 7170 | iljitsch@muada.com 10.00% | 1 | 13.61% | 4986 | jim.bound@hp.com 10.00% | 1 | 11.06% | 4053 | tony.li@tony.li 10.00% | 1 | 10.34% | 3789 | huitema@windows.microsoft.com 10.00% | 1 | 9.98% | 3655 | marcelo@it.uc3m.es 10.00% | 1 | 8.48% | 3105 | dhc@dcrocker.net 10.00% | 1 | 7.05% | 2583 | sra@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 10 |100.00% | 36632 | 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 Tue Aug 24 04: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 EAA13625 for ; Tue, 24 Aug 2004 04:21:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzWWB-0000WC-4d for multi6-data@psg.com; Tue, 24 Aug 2004 08:18:59 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzWW0-0000V4-6U for multi6@ops.ietf.org; Tue, 24 Aug 2004 08:18:48 +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 i7O8IlGP146370 for ; Tue, 24 Aug 2004 08:18:47 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 i7O8IkKS218786 for ; Tue, 24 Aug 2004 10:18:46 +0200 Received: from zurich.ibm.com (sig-9-146-225-16.de.ibm.com [9.146.225.16]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA59810 for ; Tue, 24 Aug 2004 10:18:46 +0200 Message-ID: <412AF9E5.40605@zurich.ibm.com> Date: Tue, 24 Aug 2004 10:18:45 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Multi6 milestones Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit We've agreed the following updated milestones with our AD. They are taking a little too long to appear on the official charter page, so here they are FYI: Oct 04 Submit informational I-D to IESG on how multihoming is done today Oct 04 Submit informational I-D to IESG on security threats Nov 04 Submit informational I-D to IESG on architectural evaluation Dec 04 Identify proposal(s) for further development, recharter Jan 05 Submit informational I-D to IESG on practical questions Brian Carpenter co-chair From owner-multi6@ops.ietf.org Sun Aug 29 00:02: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 AAA28871 for ; Sun, 29 Aug 2004 00:02:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1Grs-000AOJ-IV for multi6-data@psg.com; Sun, 29 Aug 2004 04:00:36 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C1Grh-000AN1-Ug for multi6@ops.ietf.org; Sun, 29 Aug 2004 04:00:26 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 09C05640 for ; Sun, 29 Aug 2004 00:00:25 -0400 (EDT) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 29 Aug 2004 00:00:24 -0400 Message-Id: <20040829040025.09C05640@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 1 | 52.02% | 2550 | brc@zurich.ibm.com 50.00% | 1 | 47.98% | 2352 | sra@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 4902 | 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.