From owner-multi6@ops.ietf.org Tue Jul 1 19:34:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20554 for ; Tue, 1 Jul 2003 19:34:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XUba-000Lk6-Ec for multi6-data@psg.com; Tue, 01 Jul 2003 23:32:10 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.14) id 19XUbW-000LjQ-Ab for multi6@ops.ietf.org; Tue, 01 Jul 2003 23:32:06 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19XUbV-0006M2-Ts for multi6@ops.ietf.org; Tue, 01 Jul 2003 16:32:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200307011902.PAA11315@ietf.org> To: IETF-Announce: ; Cc: "RFC Editor" , "Internet Architecture Board" , multi6@ops.ietf.org Subject: Document Action: Goals for IPv6 Site-Multihoming Architectures to Informational Date: Tue, 01 Jul 2003 15:02:09 -0400 From: Michael Lee X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_30,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has approved the Internet-Draft 'Goals for IPv6 Site-Multihoming Architectures' as an Informatinal RFC. This document is the product of the Site Multihoming in IPv6 Working Group. The IESG contact persons are Randy Bush and Bert Wijnen From owner-multi6@ops.ietf.org Sun Jul 6 14:13:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18836 for ; Sun, 6 Jul 2003 14:13:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ZDxw-00033h-Gw for multi6-data@psg.com; Sun, 06 Jul 2003 18:10:24 +0000 Received: from [195.43.225.70] (helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.14) id 19ZDxk-000336-OI for multi6@ops.ietf.org; Sun, 06 Jul 2003 18:10:12 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h66IABKL005309 for ; Sun, 6 Jul 2003 20:10:14 +0200 (CEST) Date: Fri, 4 Jul 2003 18:47:09 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=fixed Subject: Draft Agenda From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <275947C0-AE3F-11D7-A295-000393A638B2@kurtis.pp.se> X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-10.4 required=5.0 tests=BAYES_30,PGP_SIGNATURE,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, below you will find the draft agenda for the Vienna IETF meeting, for the two multi6 sessions. Presentations are in the order they have asked to present, and time have been allocated as people have asked for it. Notice that this a) Leaves us with an extra hour in the second session b) Although I would like us to save deeper discussions for the open mike in the second slot, I think some of the time estimates in the first slot might be optimistic and if we are getting delayed we might want to move some presentations to the second slot as well. Best regards, - - kurtis - Monday Slot *********** draft, presenter, time - - Agenda bashing, welcome, etc, Chairs, 5 min - - draft-nikander-hip-mm-00.txt, Pekka Nikkander, 5 min For background: draft-moskowitz-hip-arch-03.txt draft-moskowitz-hip-07.txt - - draft-coene-sctp-multihome-04.txt, Lode Coene, 15 min - - draft-bagnulo-multi6-mnm-00.txt, Marcelo Bagnulo, 10 min - - draft-ohira-assign-select-e2e-multihome-00.txt and draft-arifumi-lin6-multihome-api-00.txt, FUJIKAWA Kenji, 15 min - - draft-ohta-multihomed-isps-00.txt, Masataka Ohta, 10 min - - draft-ohta-e2e-multihoming-05.txt, Masataka Ohta, 20 min - - draft-de-launois-multi6-naros-01.txt, Cedric de Launois, 10 min - - draft-huitema-multi6-hosts-02.txt, Chistian Huitema & David Kessens, 20 min - - draft-savola-multi6-asn-pi-00.txt, Pekka Savola, 10 min - - draft-savola-multi6-nowwhat-00.txt, Pekka Savola, 15 min Wednesday slot ************** - - Administriva, Chairs, 5 min - - Presentation from the design team, TBD, 20 min - - Open Mike, Chairs, 60 min - - Future path for the mutli6 WG, Chairs, 20 min. Reserve time : 55 min -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPwWvkaarNKXTPFCVEQK6uwCeNiYcfHyLJLqGsnETJLOZOfY+EgsAoOPA ySqpSItiYnSTP/oMRdm9sMoi =8Hn4 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Jul 9 11:05:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03952 for ; Wed, 9 Jul 2003 11:05:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19aGU0-000MwS-2w for multi6-data@psg.com; Wed, 09 Jul 2003 15:03:48 +0000 Received: from [127.0.0.1] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 4.14) id 19aGTU-000Muq-Dn for multi6@ops.ietf.org; Wed, 09 Jul 2003 15:03:16 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19aGTT-00033y-HG for multi6@ops.ietf.org; Wed, 09 Jul 2003 17:03:15 +0200 Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Content-Transfer-Encoding: 7bit Message-Id: <8DEEF410-B201-11D7-A22A-000393A638B2@netnod.se> Date: Wed, 9 Jul 2003 13:36:17 +0200 Subject: Updated agenda for multi6 Cc: agenda@ietf.org To: multi6@ops.ietf.org From: Kurt Erik Lindqvist X-Spam-Status: No, hits=-11.5 required=5.0 tests=BAYES_10,PGP_SIGNATURE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Hash: SHA1 Monday Slot *********** draft, presenter, time - - Agenda bashing, welcome, etc, Chairs, 5 min - - draft-nikander-hip-mm-00.txt, Pekka Nikkander, 5 min For background: draft-moskowitz-hip-arch-03.txt draft-moskowitz-hip-07.txt - - draft-coene-sctp-multihome-04.txt, Lode Coene, 15 min - - draft-bagnulo-multi6-mnm-00.txt, Marcelo Bagnulo, 10 min - - draft-ohira-assign-select-e2e-multihome-00.txt, FUJIKAWA Kenji, 5 min - - draft-arifumi-lin6-multihome-api-00.txt, Arifumi Matumoto, 10 min - - draft-ohta-multihomed-isps-00.txt, Masataka Ohta, 10 min - - draft-ohta-e2e-multihoming-05.txt, Masataka Ohta, 20 min - - draft-de-launois-multi6-naros-01.txt, Cedric de Launois, 10 min - - draft-huitema-multi6-hosts-02.txt, Chistian Huitema & David Kessens, 20 min - - draft-savola-multi6-asn-pi-00.txt, Pekka Savola, 10 min - - draft-savola-multi6-nowwhat-00.txt, Pekka Savola, 15 min - - draft-van-beijnum-multi6-isp-int-aggr-01.txt, Iljitsch van Beijnum, 15 min Wednesday slot ************** - - Administriva, Chairs, 5 min - - Presentation from the design team, Iljitsch van Beijnum, 20 min - - Open Mike, Chairs, 60 min - - Future path for the mutli6 WG, Chairs, 20 min. Reserve time : 25 min -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPwv+NaarNKXTPFCVEQJdYgCg3slm7u+1osO9Yeqm8DQ4FqABEFQAoLhn sXNGWXBd2Qm0QBEO18XIo6g7 =Wh0G -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Jul 9 11:06:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03970 for ; Wed, 9 Jul 2003 11:06:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19aGTQ-000Mum-Ff for multi6-data@psg.com; Wed, 09 Jul 2003 15:03:12 +0000 Received: from [127.0.0.1] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 4.14) id 19aGSu-000Mtb-90 for multi6@ops.ietf.org; Wed, 09 Jul 2003 15:02:40 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19aGSt-00033t-GD for multi6@ops.ietf.org; Wed, 09 Jul 2003 17:02:39 +0200 Message-ID: <027901c34608$761cfdc0$dcafddca@dekisugi> References: <200306200036.JAA10113@necom830.hpcl.titech.ac.jp> <3wwufdp8j9.wl@bmdi2216.bmobile.ne.jp> <1056387293.525.31.camel@presto> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit From: "Kenji Ohira" To: "marcelo bagnulo" Cc: , "FUJIKAWA Kenji" Subject: Re: about draft-ohira-assign-select-e2e-multihome-00.txt (was :Re: Callfor presentations) Date: Wed, 9 Jul 2003 19:54:24 +0900 X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Marcelo, Please forgive me for my late reply. At the beginning, I revised my draft. So please read my revised draft. It can be downloaded from ftp://ftp.ietf.org/internet-draft/draft-ohira-assign-select-e2e-multihome-01.txt . > What do you mean by "the proposed way to multi-home"? > I mean, I couldn't find in the draft a description of any mechanisms to > multi-home... My proposal can be summarized as follows. 1. Assign IP addresses hierarchically. e.g.: When a site A subscribes to a local ISP L and M, a host H in the site A has addresses L:A:H and M:A:H. 2. Use source address based routing. In case of the above example, a packet with L:A:H as source address will go through ISP L and a packet with M:A:H as source address will go through ISP M. End hosts (further more, end applications) can select which ISP a packet will go through. > I guess that there should be a reference to a concrete mechanism > proposal, Otha's e2e multihoming perhaps? but there are no references in > the draft, could you clarify this form me? Too right. My draft is based on Ohta's e2e multihoming. It is my mistake that the old draft did not have reference to Ohta's draft. So I added the reference to my revised draft. Then, some points are different from Ohta's draft. First, I think that if we assign IP addresses hierarchically then all nodes do not have to know full routes. Second, we proposed to use source address based routing. It allows end hosts to select prefer route without full routes. At this time, it should be noted that source address based routing is applied only to default routes because if a node have some explicit route then it is reasonable to use that explicit route. > Besides, if i understand the draft correctly, it is about ingress > filtering and source address based routing, so have you checked C. > Huitema's draft about host centric multi-homing? Following your indicate, I read Huitema's draft and I understand that Huitema's solution is using tunnel at site exit router. It sounds good because Huitema's solution does not require any changes on end hosts and routers in a site (except for site exit routers). However, using tunnel sometimes causes routers to select not prefer route. Still more, site exit router may become single point of failure. And then, it is the most important point, we regard selecting source address as selecting route. Selecting source address is no less important for end hosts (furthermore, applications on the end hosts) to select proper route than selecting destination address. Even if there is no ingress filter, each packet should go through adequate site exit router according to its source address. At this time, it should be noted that Huitema's proposal is considerable as an option while routers and/or hosts do not support source address based routing enough. Best regards, July 9, 2003 (JST +0900) ---- Kenji Ohira Graduate School of Informatics, Kyoto University, JAPAN mailto: torus@tori.cc / ohira@net.ist.i.kyoto-u.ac.jp From owner-multi6@ops.ietf.org Wed Jul 9 19:02:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28117 for ; Wed, 9 Jul 2003 19:02:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19aNvE-000Hm1-6M for multi6-data@psg.com; Wed, 09 Jul 2003 23:00:24 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19aNui-000HiB-Hd for multi6@ops.ietf.org; Wed, 09 Jul 2003 22:59:52 +0000 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Jul 2003 15:59:22 -0700 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 09 Jul 2003 15:59:21 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Jul 2003 15:59:20 -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); Wed, 9 Jul 2003 15:59:20 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Wed, 9 Jul 2003 15:59:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: about draft-ohira-assign-select-e2e-multihome-00.txt (was :Re: Callfor presentations) Date: Wed, 9 Jul 2003 15:59:19 -0700 Message-ID: Thread-Topic: about draft-ohira-assign-select-e2e-multihome-00.txt (was :Re: Callfor presentations) Thread-Index: AcNGLNOWo1mgqd4zSPiGfQa4uLd0awAPoLmC From: "Christian Huitema" To: "Kenji Ohira" , "marcelo bagnulo" Cc: , "FUJIKAWA Kenji" X-OriginalArrivalTime: 09 Jul 2003 22:59:20.0300 (UTC) FILETIME=[BB399AC0:01C3466D] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable There are really four classes of solutions to the conflict between site = multi-homing and ingress filtering. =20 The simplest solution is to inform each provider about all the valid = prefixes for the site. This is probably OK for large sites, when the = providers have a willingness to cooperate. It is probably not a good = solution for very small sites, unless we can somehow automatize the = management of these filters. That solution does not require any change = in either hosts or routers. =20 Another solution is to make sure that hosts always pick the right exit. = For example, if a host hears announcements from several routers, it = could decide to perform some level of source routing, essentially = considering each separate router announcement as defining a different = "sub interface". This is OK for single link networks, but will not work = for routed sites. It require some change to the host implementation, no = change to the exit router implementation. =20 The third solution is to use a redirection mechanism from the routers. = It requires that exit routers be aware of ingress filtering, and of each = other. In a single link network, routers listen to each other router = announcements. When an exit router receives a packet bound to an exit = route, it checks whether there would be an ingress filtering violation. = If yes, the router redirects the packet to the proper exit -- a simple = forwarding decision in a single link network. The router could send an = ICMP redirect to the host, but there is a small problem of semantics -- = redirection is normally based on the destination address, while ingress = filtering decisions are based on the source address. If we forget = redirection, the solution does not require any change in the host = software. =20 The fourth solution is to implement some variation of source dependent = routing, so packets are routed to the right exit. ________________________________ From: owner-multi6@ops.ietf.org on behalf of Kenji Ohira Sent: Wed 7/9/2003 3:54 AM To: marcelo bagnulo Cc: multi6@ops.ietf.org; FUJIKAWA Kenji Subject: Re: about draft-ohira-assign-select-e2e-multihome-00.txt (was = :Re: Callfor presentations) [ post by non-subscriber. with the massive amount of spam, it is easy = to miss and therefore delete posts by non-subscribers. if you wish to = regularly post from an address that is not subscribed to this mailing list, send = a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Marcelo, Please forgive me for my late reply. At the beginning, I revised my draft. So please read my revised draft. It can be downloaded from ftp://ftp.ietf.org/internet-draft/draft-ohira-assign-select-e2e-multihome= -01.txt . > What do you mean by "the proposed way to multi-home"? > I mean, I couldn't find in the draft a description of any mechanisms = to > multi-home... My proposal can be summarized as follows. 1. Assign IP addresses hierarchically. e.g.: When a site A subscribes to a local ISP L and M, a host H in the site A has addresses L:A:H and M:A:H. 2. Use source address based routing. In case of the above example, a packet with L:A:H as source address will go through ISP L and a packet with M:A:H as source address will go through ISP M. End hosts (further more, end applications) can select which ISP a packet will go through. > I guess that there should be a reference to a concrete mechanism > proposal, Otha's e2e multihoming perhaps? but there are no references = in > the draft, could you clarify this form me? Too right. My draft is based on Ohta's e2e multihoming. It is my mistake that the old draft did not have reference to Ohta's draft. So I added the reference to my revised draft. Then, some points are different from Ohta's draft. First, I think that if we assign IP addresses hierarchically then all nodes do not have to know full routes. Second, we proposed to use source address based routing. It allows end hosts to select prefer route without full routes. At this time, it should be noted that source address based routing is = applied only to default routes because if a node have some explicit route then it is reasonable to use that explicit route. > Besides, if i understand the draft correctly, it is about ingress > filtering and source address based routing, so have you checked C. > Huitema's draft about host centric multi-homing? Following your indicate, I read Huitema's draft and I understand that Huitema's solution is using tunnel at site exit router. It sounds good because Huitema's solution does not require any changes on end hosts and routers in a site (except for site exit = routers). However, using tunnel sometimes causes routers to select not prefer route. Still more, site exit router may become single point of failure. And then, it is the most important point, we regard selecting source address as selecting route. Selecting source address is no less = important for end hosts (furthermore, applications on the end hosts) to select = proper route than selecting destination address. Even if there is no ingress = filter, each packet should go through adequate site exit router according to its source address. At this time, it should be noted that Huitema's proposal is considerable as an option while routers and/or hosts do not support source address based routing enough. Best regards, July 9, 2003 (JST +0900) ---- Kenji Ohira Graduate School of Informatics, Kyoto University, JAPAN mailto: torus@tori.cc / ohira@net.ist.i.kyoto-u.ac.jp From owner-multi6@ops.ietf.org Thu Jul 10 05:59:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24438 for ; Thu, 10 Jul 2003 05:59:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19aYBl-000FgF-Cw for multi6-data@psg.com; Thu, 10 Jul 2003 09:58:09 +0000 Received: from [130.104.229.109] (helo=info.ucl.ac.be) by psg.com with esmtp (Exim 4.14) id 19aYBd-000Ffc-Ty for multi6@ops.ietf.org; Thu, 10 Jul 2003 09:58:02 +0000 Received: from descartes.info.ucl.ac.be (descartes [130.104.229.82]) by info.ucl.ac.be (8.12.9/8.12.8) with ESMTP id h6A9u8Yb009361; Thu, 10 Jul 2003 11:56:09 +0200 (MET DST) Subject: Re: about draft-ohira-assign-select-e2e-multihome-00.txt From: Cedric de Launois To: Kenji Ohira Cc: multi6@ops.ietf.org In-Reply-To: <027901c34608$761cfdc0$dcafddca@dekisugi> References: <200306200036.JAA10113@necom830.hpcl.titech.ac.jp> <3wwufdp8j9.wl@bmdi2216.bmobile.ne.jp> <1056387293.525.31.camel@presto> <027901c34608$761cfdc0$dcafddca@dekisugi> Content-Type: text/plain; charset=ISO-8859-1 Organization: Universite Catholique de Louvain Message-Id: <1057831140.25182.59.camel@descartes> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 10 Jul 2003 11:59:00 +0200 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-31.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Le mer 09/07/2003 à 12:54, Kenji Ohira a écrit : > My proposal can be summarized as follows. > 1. Assign IP addresses hierarchically. > e.g.: When a site A subscribes to a local ISP L and M, a host H in > the site A has addresses L:A:H and M:A:H. > 2. Use source address based routing. > In case of the above example, a packet with L:A:H as source > address will go through ISP L and a packet with M:A:H as source > address will go through ISP M. End hosts (further more, end > applications) can select which ISP a packet will go through. > AFAIK the 2 points above were also suggested in Huitema's draft. >From my point of view your suggestion is : 1. Use Huitema's Host-Centric Multihoming with source-base routing 2. Let the end-hosts' applications decide which source address to use, i.e. change end-hosts' API and applications (this is not clear in your draft) Is that correct ? If yes, how do you perform the source address selection ? Does that mean that all applications on the end hosts need to be modified in order to benefit from multihoming ? Cédric From owner-multi6@ops.ietf.org Fri Jul 11 03:07:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18851 for ; Fri, 11 Jul 2003 03:07:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19arwt-000Itx-EE for multi6-data@psg.com; Fri, 11 Jul 2003 07:04:07 +0000 Received: from [218.123.132.56] (helo=yakitori.no-ip.com ident=qmailr) by psg.com with smtp (Exim 4.14) id 19arwp-000It4-Uv for multi6@ops.ietf.org; Fri, 11 Jul 2003 07:04:04 +0000 Received: (qmail 25738 invoked by uid 0); 11 Jul 2003 07:04:00 -0000 Received: from unknown (HELO dekisugi) (torus@43.245.192.22) by yahoobb218123132056.bbtec.net with SMTP; 11 Jul 2003 07:04:00 -0000 Message-ID: <040d01c3477a$9a7c3780$dcafddca@dekisugi> From: "Kenji Ohira" To: "Christian Huitema" , "marcelo bagnulo" Cc: , "FUJIKAWA Kenji" References: Subject: Re: about draft-ohira-assign-select-e2e-multihome-00.txt (was :Re: Callfor presentations) Date: Fri, 11 Jul 2003 16:03:59 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Huitema, > There are really four classes of solutions to the conflict between > site multi-homing and ingress filtering. > The simplest solution is to inform each provider about all the valid prefixes for the site. > Another solution is to make sure that hosts always pick the right exit. > The third solution is to use a redirection mechanism from the routers. > The fourth solution is to implement some variation of source dependent routing, > so packets are routed to the right exit. Your analysis is so thorough that the method which I propose is classified into the fourth of your classification. However, I think that the most essential difference between you and me is the goal. As you said above, your goal is to get around ingress filter in multihoming environment. On the other hand, my goal is that end hosts (to be exact, applications which run on those hosts) will be able to select the adequete site exit router even if there are no ingress filters. July 11, 2003 (JST +0900) ---- Kenji Ohira Graduate School of Informatics, Kyoto University, JAPAN mailto: torus@tori.cc / ohira@net.ist.i.kyoto-u.ac.jp From owner-multi6@ops.ietf.org Fri Jul 11 03:07:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18873 for ; Fri, 11 Jul 2003 03:07:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19arx2-000Iu7-40 for multi6-data@psg.com; Fri, 11 Jul 2003 07:04:16 +0000 Received: from [218.123.132.56] (helo=yakitori.no-ip.com ident=qmailr) by psg.com with smtp (Exim 4.14) id 19arwr-000It8-Nq for multi6@ops.ietf.org; Fri, 11 Jul 2003 07:04:05 +0000 Received: (qmail 25760 invoked by uid 0); 11 Jul 2003 07:04:04 -0000 Received: from unknown (HELO dekisugi) (torus@43.245.192.22) by yahoobb218123132056.bbtec.net with SMTP; 11 Jul 2003 07:04:04 -0000 Message-ID: <040e01c3477a$9d0ec940$dcafddca@dekisugi> From: "Kenji Ohira" To: "Cedric de Launois" Cc: References: <200306200036.JAA10113@necom830.hpcl.titech.ac.jp> <3wwufdp8j9.wl@bmdi2216.bmobile.ne.jp> <1056387293.525.31.camel@presto> <027901c34608$761cfdc0$dcafddca@dekisugi> <1057831140.25182.59.camel@descartes> Subject: Re: about draft-ohira-assign-select-e2e-multihome-00.txt Date: Fri, 11 Jul 2003 16:04:03 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.9 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Cedric, > > My proposal can be summarized as follows. > > 1. Assign IP addresses hierarchically. > > 2. Use source address based routing. > AFAIK the 2 points above were also suggested in Huitema's draft. > >From my point of view your suggestion is : > 1. Use Huitema's Host-Centric Multihoming with source-base routing > 2. Let the end-hosts' applications decide which source address to use, > i.e. change end-hosts' API and applications (this is not clear in > your draft) > Is that correct ? Yes. You are faultlessly correct. > If yes, how do you perform the source address selection ? First of all, I think that multihoming can not nor should not be conclude within IP layer and that the source address selection is not issue in IP layer similarly. So, this issue is out of scope of my draft. Still more, this is why the title of my draft is not 'host-centric' but 'end-to-end' multihoming. Of course, I know that this issue is still difficult in transport or application layer. In my draft, I introduce a naive but workable method that examining each path determined by a pair of source address and destination address one by one in order of match length between the source address and destination address. Here, I would like to introduce more intelligent mechanism of selection such as your NAROS system. > Does that mean that all applications on the end hosts need to be > modified in order to benefit from multihoming ? No. I think that we can assume a certain 'typical model' of application and that extended TCP or SCTP will be able to treat with multihoming for this model. In this case, applications do not need to be modified. However, someone/some applications may require to control the parameter for multihoming by itself. For those, we have one solution by end-to-end path selection with extended socket APIs of TCP for end-to-end multihoming. A. Matsumoto, co-author of my draft, is now working on this issue. So please read draft-arifumi-lin6-multihome-api-00.txt. July 11, 2003 (JST +0900) ---- Kenji Ohira Graduate School of Informatics, Kyoto University, JAPAN mailto: torus@tori.cc / ohira@net.ist.i.kyoto-u.ac.jp From owner-multi6@ops.ietf.org Fri Jul 11 18:51:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22445 for ; Fri, 11 Jul 2003 18:51:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19b6hk-000CBt-D2 for multi6-data@psg.com; Fri, 11 Jul 2003 22:49:28 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19b6gy-000C8g-P0 for multi6@ops.ietf.org; Fri, 11 Jul 2003 22:48:41 +0000 From: Masataka Ohta Message-Id: <200307112240.HAA00644@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id HAA00644; Sat, 12 Jul 2003 07:40:40 +0900 Subject: Re: Draft Agenda In-Reply-To: <275947C0-AE3F-11D7-A295-000393A638B2@kurtis.pp.se> from Kurt Erik Lindqvist at "Jul 4, 2003 06:47:09 pm" To: Kurt Erik Lindqvist Date: Sat, 12 Jul 2003 07:40:39 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > below you will find the draft agenda for the Vienna IETF meeting, Thanks. There are a lot of ID listed. Can we ignore other IDs or are there any ID which should be read before the meeting? > - - draft-ohta-multihomed-isps-00.txt, Masataka Ohta, 10 min > > - - draft-ohta-e2e-multihoming-05.txt, Masataka Ohta, 20 min The 05 draft is revised from the previous one by including ISP multihoming issues and a design frame work section. Masataka Ohta From owner-multi6@ops.ietf.org Sun Jul 13 03:39:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29949 for ; Sun, 13 Jul 2003 03:39:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bbOc-000KUP-Dl for multi6-data@psg.com; Sun, 13 Jul 2003 07:35:46 +0000 Received: from [81.160.207.94] (helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.14) id 19bbOZ-000KU7-Nx for multi6@ops.ietf.org; Sun, 13 Jul 2003 07:35:43 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h6D7ZhKL009723; Sun, 13 Jul 2003 09:35:44 +0200 (CEST) Date: Sun, 13 Jul 2003 09:35:37 +0200 Subject: Re: Draft Agenda Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200307112240.HAA00644@necom830.hpcl.titech.ac.jp> Message-Id: <986B9C3C-B504-11D7-A22A-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-16.2 required=5.0 tests=BAYES_30,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, UPPERCASE_25_50,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> below you will find the draft agenda for the Vienna IETF meeting, > > Thanks. > > There are a lot of ID listed. > > Can we ignore other IDs or are there any ID which should be read > before the meeting? Well, there is a lot of history but I am not sure that is all that relevant for Monday. Ofcourse, having read the relevant RFCs and other drafts are always a good thing(tm) but we will not put those in the multi6-WG exam..;-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPxELzKarNKXTPFCVEQKTNgCdF+4CBLj8rfp2sI41ot9Om6f6GccAn2Zs izZcX7mRwH8jw6ev1xHAgdt/ =7qSm -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Jul 14 04:07:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00728 for ; Mon, 14 Jul 2003 04:07:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19byJq-000E4G-TN for multi6-data@psg.com; Mon, 14 Jul 2003 08:04:22 +0000 Received: from [81.160.235.37] (helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.14) id 19byJn-000E44-BZ for multi6@ops.ietf.org; Mon, 14 Jul 2003 08:04:20 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h6E84OKL010399 for ; Mon, 14 Jul 2003 10:04:25 +0200 (CEST) Date: Mon, 14 Jul 2003 10:04:15 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=fixed Subject: Volunteer scribe From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-11.3 required=5.0 tests=BAYES_20,PGP_SIGNATURE,UPPERCASE_25_50,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If someone feel like volunteering as scribe for the meeting this afternoon, please let me know. If someone also feel like 'reporting' this on the jabber session, also please let me know. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPxJkA6arNKXTPFCVEQI2lgCglgJmvxzbHWI6G6K7WZBmWGBJiVoAninF /E8kVwtWxsHERpduck3AEMP4 =xgzj -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Jul 14 08:24:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14824 for ; Mon, 14 Jul 2003 08:24:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19c2Mc-000Mke-66 for multi6-data@psg.com; Mon, 14 Jul 2003 12:23:30 +0000 Received: from [3ffe:501:100c:d120::53] (helo=shonan.sfc.wide.ad.jp) by psg.com with esmtp (Exim 4.14) id 19c2Ma-000Miz-Bd for multi6@ops.ietf.org; Mon, 14 Jul 2003 12:23:28 +0000 Received: from localhost (unknown [203.178.138.11]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id B0B765D0A4; Mon, 14 Jul 2003 21:22:57 +0900 (JST) Date: Mon, 14 Jul 2003 21:22:36 +0900 From: Julien Charbon To: Multi6 Cc: Chan-Wah Ng Subject: FYI draft-charbon-nemo-multihoming-evaluation-00.txt Message-Id: <20030714212236.04f372ab.julien@sfc.wide.ad.jp> X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.6 required=5.0 tests=BAYES_30 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello all, We have written an Internet-Draft on the evaluation of Multi-Homing support by NEMO Basic solution [1]. The Multi-Homing being a wide problematic maybe some part of this document can be useful for your information. You can check this draft at this URL: [http://www.sfc.wide.ad.jp/~julien/papers/draft-charbon-nemo-multihoming-evaluation-00.txt] Thanks. -- Julien Charbon & Chan-Wah Ng [1] http://www.ietf.org/html.charters/nemo-charter.html From owner-multi6@ops.ietf.org Mon Jul 14 13:08:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05660 for ; Mon, 14 Jul 2003 13:08:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19c6kO-0008Wh-4h for multi6-data@psg.com; Mon, 14 Jul 2003 17:04:20 +0000 Received: from [2001:360::4] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.14) id 19c6kD-0008Vh-T4 for multi6@ops.ietf.org; Mon, 14 Jul 2003 17:04:10 +0000 Received: from gih505.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h6EH2wQB007364; Tue, 15 Jul 2003 03:03:11 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20030715025859.01bd45f8@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Jul 2003 03:02:32 +1000 To: Kurt Erik Lindqvist , multi6@ops.ietf.org From: Geoff Huston Subject: IETF 57 Multu6 WG - Monday morning session - minutes Cc: proceedings@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_30,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Multi 6 Monday 1300 - 1500 Agenda - overview of submitted drafts Agenda bashing: none - - draft-nikander-hip-mm-00.txt, Pekka Nikkander, 5 min For background: draft-moskowitz-hip-arch-03.txt draft-moskowitz-hip-07.txt Host Identity Protocol (HIP) has been around for some time. New namespace protocol with a history of around 4 years. Today sockets are bound to IP addresses, forcing the IP address into a dual role of endpoint identifiers and forwarding identifiers. HIP introduces a new namespace between the network and transport layers. The sockets are bound to host identifiers that are dynamically bound to IP addresses. Hosts are identified with public keys, not IP addresses, and apps see only the HIP identifiers. The apps need not change is the assertion. Hosts can easily have both IPv4 and IPv6 addresses, and the assertion is that end-host multi-homing and mobility is trivial. HIP Proxies are described as a kind of a hack. HIP may be a part of the multi-homing architecture. 4 Interoperating implementations, intend to send the drafts to the IESG, and more work is needed on mobility and multi-homings with NAT traversal. HIP is not a working group but is progressing in the background. HIP is a multi-address solution with end-to-end. It solves only one aspect of multi6, and has no specific solns for address selection or TE Matsataka Ohta: You said "HIP Proxy" - do you support multi-proxies for backup Pekka Nikkander: There is no easy way to have multi HIP proxies in some situations, and it does represent a single point of failure - - draft-coene-sctp-multihome-04.txt, Lode Coene, 15 min SCTP approach - endpoints have multiple addresses, where each IP address represents a path to a particular endpoint. SCTP is not aware of the level of path distinguishing - it would be good if they were, but this is not a known property. SCTP can detect path up/down. (Example of host-to-host with 2 addrs on each host). Multi-homing open up new horizons for SCTP: add and remove ip addresses dynamically to the endpoint, that can support mobility. Functionality at the endpoint is asserted to be superior to network functions in this regards. It does imply that the host requires a routing table - not a big deal for a host is the claim. But a big table is required for a system with a large connection load. How to maintain the routing table is claimed to be implementation dependant (pre-configured or caching the INIT). NATs are in the draft because they wanted to warn everyone how bad NATs really are! NAT cases for SCTP generates problems that do no appear to have straightforward solutions. From the transport level SCTP is claimed to be a 'should work' solution. Lixia Zhang: How about UDP? Lode Coene: its the same problem, with the application having to undertake the selection. Erik Nordmark: what algorithms have been used in SCTP work to select source and destinations? Any write ups of this work? Lode Coene: none known to me. - - draft-bagnulo-multi6-mnm-00.txt, Marcelo Bagnulo, 10 min Proposes to use MIPv6 to the multi-homing (mh) problem. Example in presentation of recovery from current to backup path (Using alternate addresses) Both paths have to be bound and identified _before_ an outage using binding update messages. The alternate binding will use the Home Address Option. Since MIP already needs the exchange of messages along each path, this exchange can be used as a path keepalive. The lifetime of the binding is limited to 7 minutes, and this is considered to be very short. Possible solutions are proposed Matsataka Ohta: IPv6 has large timeouts for various purposes. If your proposal to have the same property so that the new address can be used quickly. Marcelo Bagnulo: this issue is to build a path outage detection, and we are proposed to use the packet exchange for this purpose. The idea is to use the same packet format, but change the timing. - - draft-ohta-e2e-multihoming-05.txt, Masataka Ohta, 20 min General introduction on IP and IPv6. References 8+8 Locator and endpoint I-D. The proposal is to let end systems have multiple addresses. Let the other end select the 'best' address. (The host addresses are part of multiple upstream aggregates). The general architecture proposed is to let the network inform the host about state to allow the hosts to undertake address selection. When should a host attempt alternate addresses? Proposed in response to ICMP, routing change, timeouts (TCP only). Proposed that applications have an IP (and UDP)-defined packet timeout to trigger alternate address use. For very short timeouts it is proposed to send multi-copies of the packet with multiple addresses. e-2-e mh and IP mobility are similar, although there is mobility timing at the IP layer. e2emh has been implemented and running on NetBSD with LIN6, with modifications to the stack as described in the presentation. The design framework proposed is to make everything optional. Exercising no options is single-homed. Use 8+8 Locator/Id separation, with packet reception and connection identification determined by the ID. Application to mobility is also described. Multiple addresses are supplied to the peer by reverse query of DNS using an ID query key followed by a forward query, or carry in the TCP header or a new DNS query type. e2e approach is proposed as scaleable architecture. MH and mobility are related, and the approach uses 8+8 separation Pekka Nikkander: You did not mention security issues in your presentation - is this to be addressed later on, or do you have comments now? Matasaka Ohta: The current Internet is weakly secure. Cookie-based security for locator change give only the same level of security. Peter Werny: What is required in the DNS for this to work? Matasaka Ohta: this is different from current V6, as it only uses the identifier 8 bytes. In DNS we look up locators of location agents using ID of hosts. Peter Werny: Every host has to have a DNS entry? Matasaka Ohta:If there is no DNS and not TCP then you are single-homed, and you cannot use this mechanisms. PW: Your draft has no mention of DNS update Matasaka Ohta: Location is not in the DNS - just the location agent. Erik Nordmark: Are you assuming a structure for the identifiers? Matasaka Ohta: It should be reverse lookup-able. Its better to have hierarchy in the identifier space, but you can do without hierarchy if you use TCP instead of the DNS to pass the multiple addresses - - draft-ohira-assign-select-e2e-multihome-00.txt, FUJIKAWA Kenji, 5 min Each end application can determine a route to use. Applications select a route using a selection of a specific source and destination address pair. An end application can select a path without full route information is the claim. The attributes are claimed to include redundancy and load balancing. Modifications to hosts, routers and routing protocols is needed. Site exit router selection using source address routing enables redundancy, load sharing with multiple paths. Some mechanisms is needed for 'proper' source address selection. Transport layer survivability could be an SCTP mechanism or other. - - draft-arifumi-lin6-multihome-api-00.txt, Arifumi Matumoto, 10 min Socket API extensions. Propose to use application layer, rather than the network. Uses 8+8 model. The API is for manipulation of multiple addresses in the application. LIN6 is based on the 8+8 model. LIN6 does address acquisition, notification, registration in a secure manner. Hosts identify their peer and themselves using only the identifier part. e2e-mh is seen to be an application of the LIN6 model. The trigger to switch locators is seen to be ICMP-based using host unreachable. APIs need to manipulate locators, to make a multi-locator-ready socket, allow API to change locators on the fly, and acquire remote locators. The details of API changes described, in socket(), getaddrinfo() and getsockopt()/setsocketopt(). APIs are intended for active mh applications. UDP requires application support. Future work is to put support in to the TCP level, so that no changes are required for API for TCP. - - draft-ohta-multihomed-isps-00.txt, Masataka Ohta, 10 min All hosts should have full default-free routing table. This allows selector in host to make optimal locator choice, and know when locator is unreachable. source address selection for ingress filtering only. The peer will not use the source address - it will make its own selection of a locator for the peer. Extended example of policy control and filtering. Pekka Savola: Both of these drafts have been obsoleted Matasaka Ohta: not a problem! ? (MCI): IF an NLA gets address space from 2 TLAs which does it use? MO: If gets 2 addresses, as does its customers. The number of prefixes cascades down. ? MCI): Scaleaility? MO: yes, and NLA should be no more than triply homed. Iljitsch van Beijnum: Why is the information in the routing table superior to information you can obtain from the other end? MO: This does not have scaleability problems if you limit connectivity. This is a connectionless system where a host has no information about the other end, and the routing table is local information you can use. Iljitsch van Beijnum: ok, but I disagree with this - - draft-de-launois-multi6-naros-01.txt, Cedric de Launois, 10 min Solution for traffic engineering for mh need sites in a multi-address environment. Each host has 1 address per upstream provider. Noted that choosing a source address implies choosing a provider (assuming providers perform source address filtering). Which source? A host has no information about which provider to use to reach a destination. Propose to use a dedicated agent (server). A host will query the server with a destination address, and the server responds with the source to use. The burden of selecting the source address is aggregated to a dedicated server. Note it gives only a hint to the host about what address to use. NAROS is not intended to preserve flows across address changes. SCTP or HIP could be used to preserve flows. The server could be anycast, or undertaken without provider interaction. The host / server protocol is a query response packet exchange. Where multiple choices exist, multiple parameters can be used to make the selection. Pekka Nikkander: is this a new protocol, or, perhaps, ICMP Cedric de Launois: No particular protocol - it could be ICMP PN: There are security issues here, like secure neighbor discovery Michael Richardson: Takes the example and adds further connections, and then adds a policy question about 'acceptable traffic' policies. Can NAROS deal with this> CdL: A lot of requirements could be placed in the NAROS server and it could be aware of those kind of requirements. Matsataka Ohta: Anycast does not include increased robustness for server failure. A NAROS server crash will not bring down a anycast route. Also 300 seconds is too large a value. - - draft-huitema-multi6-hosts-02.txt, Chistian Huitema & David Kessens, 20 min Simple multihoming experiment. A problem statement in a bounded example environment. A simple network is a single link where multiple hosts see multiple boundary routers where each router is connected to distinct upstreams. Addresses from providers are mapped to all the hosts. Asserted that this is not uncommon in V4 and that the common solution is to NAT the local net and allow the NAT to 'rehome' to each outbound. The consequence is flow breakage across the rehoming of the NAT. The bounds are that the ISPS do not exchange information, there are provider addresses with an assigned prefix per provider. Hosts configure an address with each prefix. Need to resolve host choice of egress router selection (as a function of the source address) Erik Nordmark: There are people talking about movement detection, and this gets all routers to advertise all prefixes Christian Huitema: Thats not incompatible - several routers can advertise the same information, provided that the information is equivalent, and the routers can handle all such packets. Pekka Savola: please clarify the applicability. This is only the case where hosts are directly connected to all egress routers. Christian: this is a common case. MO: You don't need tunnels in a single link network. In a multi-link network you need tunnels. CH: This does nothing for MTU discovery. For single link there is a very simple solution and this can be extended for multi-links MO: Ands I'm saying its impossible CH: fine! No need for tunnels in a single link network, and the routers can pass off to each other in the event of dynamic failure. The assertion is that in a single link network this requirement can be easily met. Dead exist routers or dead ISP require some consideration. If the exit router knows that the path is dead it can send a poison advertisement of the prefix. The real issue with this form of mh is a very soft definition of 'broken' where the link may be up, but the path to the remote end point may be unuseable. This kind of problem is an e2e detection issue. Hosts may need to keep track of connections and track quality. If you know an ingress path is dead do you need to update the DNS to remove the dead prefix from your host entry? Of course you may not know and in this case your peer will need to work out what address to use. Maintenance of TCP connections is an issue. MIP6 may be an answer, or SCTP for 'new hosts'. For 'old' hosts, he connection will fail, and needs to be reestablished. Exit / entrance selection is also an issue. One approach is to only advertise the preferred address in the DNS if you have a primary / backup scenario. And in a 1 + 1 scenario, then advertise both. On the outgoing the solution may be a local server to assist, or to document preferences in the routers. We appear to be able to design solutions that require changes to the IPv6 standards, do no require address rewriting at exit points, but it could work, Pekka Nikkander: New hosts can use MIPv6 or SCTP. IN MIPv6 don't you need to change both ends? CH: The support for the connected node in MIPv6 is supposed to be implemented everywhere. PN: You need to change the address in both ends. CH: The time appears to be around 5 or 6 minutes. PN: If you are going to change the code at both ends then you should try HIP in your experiments as well. CH: You are free to experiment with HIP Fujikawa: It seems like an application cannot select different path from other applications in a host? CH: No, not so. The host has several IPv6 addresses. An application that want to do path selection can bind to a source address and connect to a destination and select a path. Matasaka Ohta: It is stupid to keep using a complication MIPv6 CH: Complexity is management of the Home agent and security functions to certain classes of attacks and you will need to have some form of security in any case. Matasaka Ohta: This only works in a single link case. In a larger site the problem is ingress filtering, because its harder to do source-based routing. The simple solution is to work with the ISP to lift source filters. Even larger sites have their own PI space and AS#. IvB: Disable ingress filtering can be down for the local upstream, but the chain may extend upward CH: ingress filtering in the middle of the Internet is a bad idea MO: what will you do with a large site? CH: lets call them medium Bob Hinden: ISPs would be more amenable to break ingress filtering than route specifics. ?: Ingress filtering should not be an issues. Mat Ford: Define a large site? CH: establish a registry relationship! - - draft-savola-multi6-asn-pi-00.txt, Pekka Savola, 10 min Claimed that this is not the best solution in all cases, but better than some others. Need to avoid the routing mess of advertising more specific and need solutions soon. Approach to use the AS number to create PI space for larger enterprises. e.g. 2000:::/32. Issues about 16 / 32 bit AS numbers, and a claim that 32 bit AS numbers would indicate a RIR policy failure. Moshens VC(?): How do you get uniqueness of the prefix PS: This is 2000 - it won't collide! MO: There are already too many ASes deployed Geoff Huston: You are assuming AS remain at 16bits. What happens when AS drain in 2011. and we move to 32 bit AS numbers? This is a relatively short term solution with a visible drop dead point - right? PV: yes. ?: This is good solution PV: an appendix shows how to deal with 32 bit AS numbers, but I don't lkike this solution. Tim Chen: This cuts out the smaller sites that do not have ASs. Randy Bush: Why reluctant to give out ASes to routing domains who's policy domains are different from their neighbors? - - draft-van-beijnum-multi6-isp-int-aggr-01.txt, Iljitsch van Beijnum, 15 min Geographical aggregation. Admitted that topology is not correlated to geography, and even if the geo part doesn't work there are still some savings. MH: This gives little actual aggregation ?: Asymmetrical routes break in your model IvB: Routing is asymmetrical in multi-homing in any case. Tony Hain: Aggregatibility is the question. The concept appears fine, but you are making assumptions about aggregation boundaries here. From owner-multi6@ops.ietf.org Tue Jul 15 02:57:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26649 for ; Tue, 15 Jul 2003 02:57:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cJir-000IMR-Jk for multi6-data@psg.com; Tue, 15 Jul 2003 06:55:37 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19cJin-000IM4-DK for multi6@ops.ietf.org; Tue, 15 Jul 2003 06:55:33 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6F6txxS026099; Tue, 15 Jul 2003 08:56:00 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 14 Jul 2003 23:34:42 +0200 Subject: Re: IETF 57 Multu6 WG - Monday morning session - minutes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org, proceedings@ietf.org To: Geoff Huston From: Iljitsch van Beijnum In-Reply-To: <5.1.0.14.2.20030715025859.01bd45f8@localhost> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.0 required=5.0 tests=BAYES_01,DATE_IN_PAST_06_12,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On maandag, jul 14, 2003, at 19:02 Europe/Amsterdam, Geoff Huston wrote: > - - draft-van-beijnum-multi6-isp-int-aggr-01.txt, Iljitsch van Beijnum, > 15 min > Geographical aggregation. Admitted that topology is not correlated > to geography, and even if the geo part doesn't work there are still > some savings. I did say a little more than that... I'll put the slides up at http://www.muada.com/ietf57-isp-int.pdf as soon as I'm online again (which should be around the time this message gets out). In the mean time: - Goal is enabling multihoming ASAP. This is a short term solution. - It works by distributing the global routing table over the routers within an (ISP) network rather than giving every router a full copy as is done today. - This would lead to scenic routing but the geo aspect repairs this. - Unless there is insufficient interconnection between networks, then aggregation must be broken. - Geographic aggregates are internal to each network and not annouced externally. - Correlation between topology and geography is less than 1, but also more than 0 and even without geography there are still some savings. - No real downsides: RIRs must implement geographic address allocation, ISPs can implement this (or not) at their convenience. > MH: This gives little actual aggregation > ?: Asymmetrical routes break in your model > IvB: Routing is asymmetrical in multi-homing in any case. What I said was: today it's assymmetrical anyway (re hot potato routing) and when both sides do geo aggregation it is still assymmetrical, when one end is geo multihomed and the other isn't it's symmetrical. But read the draft as it has a section on exactly this issue from an ISP traffic distribution viewpoint. > Tony Hain: Aggregatibility is the question. The concept appears fine, > but you are making assumptions about aggregation boundaries here. Short answer: you can make your own boundaries or this can even work with your (Tony's) geographic addressing plan. Long answer: no time for the long answer... From owner-multi6@ops.ietf.org Tue Jul 15 04:20:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03248 for ; Tue, 15 Jul 2003 04:20:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cL1D-000Nrd-Ns for multi6-data@psg.com; Tue, 15 Jul 2003 08:18:39 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19cL18-000NrR-H5 for multi6@ops.ietf.org; Tue, 15 Jul 2003 08:18:34 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6F8JFxS027014 for ; Tue, 15 Jul 2003 10:19:15 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 15 Jul 2003 10:18:33 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: yesterday From: Iljitsch van Beijnum To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-6.2 required=5.0 tests=BAYES_20,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Some random thoughts on the session yesterday: I once again want to object to the idea of putting a full routing table in each host, as suggested by Masataka Ohta. I see a lot of practical problems with this, I'm almost certain we need to create more or less a completely new protocol for this to work as the only protocol that has the right information is BGP but BGP needs manual configuration and that is NOT something you want to do for each host. Then there is the unnecessary resource consumption (IPv4 table using Zebra costs at least 60 MB, a third of which is kernel memory wich can't be swapped out). But the more fundamental problem is that all the really good stuff is aggregated away in the global routing table, so the info you can derive from that is by far inferior to what you can get from talking to the other side. I don't mean _asking_ the other side, I mean doing measurements on the packets going back and forth, the same way TCP does to arrive at good round trip times. Also, the NAROS approach gives nodes access to info in the routing table too without many of the drawbacks. Although I hope NAROS does more than just look at BGP or it has the same problem. But that shouldn't be a problem: a NAROS server could also look at the line utilization for different connections and do traffic engineering. Some other thoughts on NAROS: - Timeouts are bad. They are always too long or too short. An additional way to handle invalidating caches in hosts would be to send out a multicast message for this. This way, the NAROS server can invalidate all caches and maybe even trigger rehoming of existing sessions when something significant happens to external connectivity. - Probably controversial: why first do a name lookup and then a NAROS lookup? NAROS could be a superset of DNS so a host could ask the NAROS server for info on a FQDN and get everything it would normally get from a DNS server and then the address preference info. This is just an optimization of the lookup process, I'm not proposing any changes to the the DNS here. - Hosts could send information they discover over the course of a session back to the NAROS server so that it can help other hosts. For instance, if a correspondent host has two addresses and the NAROS server doesn't have a strong feeling about which is better, and one doesn't work, the host sends back "this address didn't work" and then the server can lower the priority for this address so the next host will try the other address first. I think NAROS has the potential to be a very powerful tool, which means it propably needs to be "bigger" than the author(s) originally anticipated. It would be a shame to standardize this in a way that soon becomes too constricting for what people actually want to do. On the 16 bit AS == PI prefix thing: this is just plain a very bad idea. In the first place, it doesn't scale. Second, it WILL create a land rush as it's very easy to get an AS number (hi Michel). Third, current practice is already that the people with enough money that really want it can get their own prefix, so there is no need to specifically address this small group. I did like a lot of the end-to-end, host centric and so on stuff, however, it seems to me that a lot of this doesn't include the latest wisdom on this subject. For instance, some form of 8+8 came up but there was no explanation about how this can work with autoconfiguration, how badly it breaks transport protocols and so on. Also, some mechanisms (such as SCTP) need API changes. I think this is EXTREMELY dangerous as this is a huge stumbling block for IPv6 adoption. The latest OSes support IPv6 and getting a tunnel or 6to4 is fairly trivial, but we the reason why there is very little IPv6 adoption is that the applications simply fail to use it when it's available. This is something we absolutely can't have with multihoming, in my not so humble opinion. From owner-multi6@ops.ietf.org Tue Jul 15 04:40:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05123 for ; Tue, 15 Jul 2003 04:40:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cLLy-000Oxf-J2 for multi6-data@psg.com; Tue, 15 Jul 2003 08:40:06 +0000 Received: from [81.160.235.37] (helo=laptop2.ietf57.telekom.at) by psg.com with esmtp (Exim 4.14) id 19cLLq-000Owf-Ty for multi6@ops.ietf.org; Tue, 15 Jul 2003 08:39:59 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.ietf57.telekom.at (8.12.9/8.10.2) with ESMTP id h6F8dtZC000429; Tue, 15 Jul 2003 10:39:55 +0200 (CEST) Date: Tue, 15 Jul 2003 10:39:51 +0200 Subject: Re: yesterday Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Some random thoughts on the session yesterday: Wait! This is what we are supposed to do tomorrow! :-) > Also, some mechanisms (such as SCTP) need API changes. I think this is > EXTREMELY dangerous as this is a huge stumbling block for IPv6 > adoption. The latest OSes support IPv6 and getting a tunnel or 6to4 is > fairly trivial, but we the reason why there is very little IPv6 > adoption is that the applications simply fail to use it when it's > available. This is something we absolutely can't have with > multihoming, in my not so humble opinion. I think this brings up the issues from the IAB meeting yesterday, what do we want to change when. That we need to change large parts at some point, I think is clear. Question is if this will really influence IPv6 adoption or not (if the change takes us 10+ years - after we have consensus, is it really an issue). And what we do in the mean time. It will be interesting to see what the IAB comes up with. I personally think that Brians presentation from yesterdays IAB meeting was very good and pointed to the problems. And the problems with the solutions. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPxO92aarNKXTPFCVEQKSUACdEWJEOqFgtcgSab4QYjF6KVdi8MUAniXX FoQzoX5uF9SLyGyc3EwHUQhN =priV -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jul 15 04:41:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05195 for ; Tue, 15 Jul 2003 04:41:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cLMo-000P1M-EB for multi6-data@psg.com; Tue, 15 Jul 2003 08:40:58 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19cLMi-000Oyx-Iw for multi6@ops.ietf.org; Tue, 15 Jul 2003 08:40:52 +0000 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Jul 2003 01:40:22 -0700 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 15 Jul 2003 01:40:21 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 01:40:18 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 01:40:18 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 01:40:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.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: IETF 57 Multu6 WG - Monday morning session - minutes Date: Tue, 15 Jul 2003 01:40:17 -0700 Message-ID: Thread-Topic: IETF 57 Multu6 WG - Monday morning session - minutes Thread-Index: AcNKK4cPySjapomVRyGbtWpKmXR30AAgBK30 From: "Christian Huitema" To: "Geoff Huston" , "Kurt Erik Lindqvist" , Cc: X-OriginalArrivalTime: 15 Jul 2003 08:40:17.0737 (UTC) FILETIME=[B7F12390:01C34AAC] X-Spam-Status: No, hits=-13.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Geoff, =20 Thanks for the notes. You made a slight typo in the reporting of my = talk, when you wrote "We appear to be able to design solutions that require changes to the IPv6 standards, = do no require address rewriting at exit points, but it could work". What I = said was, "We appear to be able to design solutions that ^do not* require changes to the IPv6 = standards, do not require address rewriting at exit points, and could work." There is also a small typo in a response to Pekka. You wrote: PN: You need to change the address in both ends. CH: The time appears to be around 5 or 6 minutes. The actual question was "you need to change code at both ends" (as = Marcello explained, you need to do something to some MIPv6 timers to be = more efficient). The response was, "You don't need to change code if you = are satisfied with the default timers, which appears to be around 5 or 6 = minutes." -- Christian Huitema ________________________________ From: owner-multi6@ops.ietf.org on behalf of Geoff Huston Sent: Mon 7/14/2003 10:02 AM To: Kurt Erik Lindqvist; multi6@ops.ietf.org Cc: proceedings@ietf.org Subject: IETF 57 Multu6 WG - Monday morning session - minutes Multi 6 Monday 1300 - 1500 Agenda - overview of submitted drafts Agenda bashing: none - - draft-nikander-hip-mm-00.txt, Pekka Nikkander, 5 min For background: draft-moskowitz-hip-arch-03.txt draft-moskowitz-hip-07.txt Host Identity Protocol (HIP) has been around for some time. New namespace protocol with a history of around 4 years. Today sockets are bound to IP addresses, forcing the IP address into a dual role of = endpoint identifiers and forwarding identifiers. HIP introduces a new namespace between the network and transport layers. The sockets are bound to host identifiers that are dynamically bound to IP addresses. Hosts are identified with public keys, not IP addresses, and apps see only the HIP identifiers. The apps need not change is the assertion. Hosts can easily have both IPv4 and IPv6 addresses, and the assertion is that end-host multi-homing and mobility is trivial. HIP Proxies are described as a = kind of a hack. HIP may be a part of the multi-homing architecture. 4 Interoperating implementations, intend to send the drafts to the IESG, = and more work is needed on mobility and multi-homings with NAT traversal. = HIP is not a working group but is progressing in the background. HIP is a multi-address solution with end-to-end. It solves only one aspect of multi6, and has no specific solns for address selection or TE Matsataka Ohta: You said "HIP Proxy" - do you support multi-proxies for = backup Pekka Nikkander: There is no easy way to have multi HIP proxies in some situations, and it does represent a single point of failure - - draft-coene-sctp-multihome-04.txt, Lode Coene, 15 min SCTP approach - endpoints have multiple addresses, where each IP = address represents a path to a particular endpoint. SCTP is not aware of the = level of path distinguishing - it would be good if they were, but this is not = a known property. SCTP can detect path up/down. (Example of host-to-host = with 2 addrs on each host). Multi-homing open up new horizons for SCTP: add = and remove ip addresses dynamically to the endpoint, that can support = mobility. Functionality at the endpoint is asserted to be superior to network functions in this regards. It does imply that the host requires a = routing table - not a big deal for a host is the claim. But a big table is = required for a system with a large connection load. How to maintain the routing table is claimed to be implementation dependant (pre-configured or = caching the INIT). NATs are in the draft because they wanted to warn everyone = how bad NATs really are! NAT cases for SCTP generates problems that do no appear to have straightforward solutions. From the transport level SCTP = is claimed to be a 'should work' solution. Lixia Zhang: How about UDP? Lode Coene: its the same problem, with the application having to = undertake the selection. Erik Nordmark: what algorithms have been used in SCTP work to select = source and destinations? Any write ups of this work? Lode Coene: none known to me. - - draft-bagnulo-multi6-mnm-00.txt, Marcelo Bagnulo, 10 min Proposes to use MIPv6 to the multi-homing (mh) problem. Example in presentation of recovery from current to backup path (Using alternate addresses) Both paths have to be bound and identified _before_ an outage using binding update messages. The alternate binding will use the Home Address Option. Since MIP already needs the exchange of messages along = each path, this exchange can be used as a path keepalive. The lifetime of the binding is limited to 7 minutes, and this is considered to be very = short. Possible solutions are proposed Matsataka Ohta: IPv6 has large timeouts for various purposes. If your proposal to have the same property so that the new address can be used = quickly. Marcelo Bagnulo: this issue is to build a path outage detection, and we = are proposed to use the packet exchange for this purpose. The idea is to use the same packet format, but change the timing. - - draft-ohta-e2e-multihoming-05.txt, Masataka Ohta, 20 min General introduction on IP and IPv6. References 8+8 Locator and = endpoint I-D. The proposal is to let end systems have multiple addresses. Let the other end select the 'best' address. (The host addresses are part of multiple upstream aggregates). The general architecture proposed is to = let the network inform the host about state to allow the hosts to undertake address selection. When should a host attempt alternate addresses? = Proposed in response to ICMP, routing change, timeouts (TCP only). Proposed that applications have an IP (and UDP)-defined packet timeout to trigger alternate address use. For very short timeouts it is proposed to send multi-copies of the packet with multiple addresses. e-2-e mh and IP mobility are similar, although there is mobility timing at the IP layer. e2emh has been implemented and running on NetBSD with LIN6, with modifications to the stack as described in the presentation. The design framework proposed is to make everything optional. Exercising no options = is single-homed. Use 8+8 Locator/Id separation, with packet reception and connection identification determined by the ID. Application to mobility = is also described. Multiple addresses are supplied to the peer by reverse query of DNS using an ID query key followed by a forward query, or carry = in the TCP header or a new DNS query type. e2e approach is proposed as scaleable architecture. MH and mobility are related, and the approach = uses 8+8 separation Pekka Nikkander: You did not mention security issues in your = presentation - is this to be addressed later on, or do you have comments now? Matasaka Ohta: The current Internet is weakly secure. Cookie-based = security for locator change give only the same level of security. Peter Werny: What is required in the DNS for this to work? Matasaka Ohta: this is different from current V6, as it only uses the identifier 8 bytes. In DNS we look up locators of location agents using = ID of hosts. Peter Werny: Every host has to have a DNS entry? Matasaka Ohta:If there is no DNS and not TCP then you are single-homed, = and you cannot use this mechanisms. PW: Your draft has no mention of DNS update Matasaka Ohta: Location is not in the DNS - just the location agent. Erik Nordmark: Are you assuming a structure for the identifiers? Matasaka Ohta: It should be reverse lookup-able. Its better to have hierarchy in the identifier space, but you can do without hierarchy if = you use TCP instead of the DNS to pass the multiple addresses - - draft-ohira-assign-select-e2e-multihome-00.txt, FUJIKAWA Kenji, 5 = min Each end application can determine a route to use. Applications = select a route using a selection of a specific source and destination address = pair. An end application can select a path without full route information is = the claim. The attributes are claimed to include redundancy and load = balancing. Modifications to hosts, routers and routing protocols is needed. Site = exit router selection using source address routing enables redundancy, load sharing with multiple paths. Some mechanisms is needed for 'proper' = source address selection. Transport layer survivability could be an SCTP = mechanism or other. - - draft-arifumi-lin6-multihome-api-00.txt, Arifumi Matumoto, 10 min Socket API extensions. Propose to use application layer, rather than = the network. Uses 8+8 model. The API is for manipulation of multiple = addresses in the application. LIN6 is based on the 8+8 model. LIN6 does address acquisition, notification, registration in a secure manner. Hosts = identify their peer and themselves using only the identifier part. e2e-mh is seen = to be an application of the LIN6 model. The trigger to switch locators is = seen to be ICMP-based using host unreachable. APIs need to manipulate = locators, to make a multi-locator-ready socket, allow API to change locators on = the fly, and acquire remote locators. The details of API changes described, = in socket(), getaddrinfo() and getsockopt()/setsocketopt(). APIs are = intended for active mh applications. UDP requires application support. Future = work is to put support in to the TCP level, so that no changes are required = for API for TCP. - - draft-ohta-multihomed-isps-00.txt, Masataka Ohta, 10 min All hosts should have full default-free routing table. This allows selector in host to make optimal locator choice, and know when locator = is unreachable. source address selection for ingress filtering only. The = peer will not use the source address - it will make its own selection of a locator for the peer. Extended example of policy control and filtering. Pekka Savola: Both of these drafts have been obsoleted Matasaka Ohta: not a problem! ? (MCI): IF an NLA gets address space from 2 TLAs which does it use? MO: If gets 2 addresses, as does its customers. The number of prefixes cascades down. ? MCI): Scaleaility? MO: yes, and NLA should be no more than triply homed. Iljitsch van Beijnum: Why is the information in the routing table = superior to information you can obtain from the other end? MO: This does not have scaleability problems if you limit connectivity. This is a connectionless system where a host has no information about = the other end, and the routing table is local information you can use. Iljitsch van Beijnum: ok, but I disagree with this - - draft-de-launois-multi6-naros-01.txt, Cedric de Launois, 10 min Solution for traffic engineering for mh need sites in a multi-address environment. Each host has 1 address per upstream provider. Noted that choosing a source address implies choosing a provider (assuming = providers perform source address filtering). Which source? A host has no = information about which provider to use to reach a destination. Propose to use a dedicated agent (server). A host will query the server with a = destination address, and the server responds with the source to use. The burden of selecting the source address is aggregated to a dedicated server. Note = it gives only a hint to the host about what address to use. NAROS is not intended to preserve flows across address changes. SCTP or HIP could be used to preserve flows. The server could be anycast, or undertaken = without provider interaction. The host / server protocol is a query response = packet exchange. Where multiple choices exist, multiple parameters can be used = to make the selection. Pekka Nikkander: is this a new protocol, or, perhaps, ICMP Cedric de Launois: No particular protocol - it could be ICMP PN: There are security issues here, like secure neighbor discovery Michael Richardson: Takes the example and adds further connections, and then adds a policy question about 'acceptable traffic' policies. Can = NAROS deal with this> CdL: A lot of requirements could be placed in the NAROS server and it = could be aware of those kind of requirements. Matsataka Ohta: Anycast does not include increased robustness for server failure. A NAROS server crash will not bring down a anycast route. Also = 300 seconds is too large a value. - - draft-huitema-multi6-hosts-02.txt, Chistian Huitema & David Kessens, 20 min Simple multihoming experiment. A problem statement in a bounded = example environment. A simple network is a single link where multiple hosts see multiple boundary routers where each router is connected to distinct upstreams. Addresses from providers are mapped to all the hosts. = Asserted that this is not uncommon in V4 and that the common solution is to NAT = the local net and allow the NAT to 'rehome' to each outbound. The = consequence is flow breakage across the rehoming of the NAT. The bounds are that the ISPS do not exchange information, there are provider addresses with an assigned prefix per provider. Hosts configure an address with each = prefix. Need to resolve host choice of egress router selection (as a function of the source address) Erik Nordmark: There are people talking about movement detection, and = this gets all routers to advertise all prefixes Christian Huitema: Thats not incompatible - several routers can = advertise the same information, provided that the information is equivalent, and = the routers can handle all such packets. Pekka Savola: please clarify the applicability. This is only the case = where hosts are directly connected to all egress routers. Christian: this is a common case. MO: You don't need tunnels in a single link network. In a multi-link network you need tunnels. CH: This does nothing for MTU discovery. For single link there is a very simple solution and this can be extended for multi-links MO: Ands I'm saying its impossible CH: fine! No need for tunnels in a single link network, and the routers can = pass off to each other in the event of dynamic failure. The assertion is that = in a single link network this requirement can be easily met. Dead exist routers or dead ISP require some consideration. If the exit router knows that the path is dead it can send a poison advertisement of the prefix. = The real issue with this form of mh is a very soft definition of 'broken' = where the link may be up, but the path to the remote end point may be = unuseable. This kind of problem is an e2e detection issue. Hosts may need to keep track of connections and track quality. If you know an ingress path is = dead do you need to update the DNS to remove the dead prefix from your host entry? Of course you may not know and in this case your peer will need = to work out what address to use. Maintenance of TCP connections is an = issue. MIP6 may be an answer, or SCTP for 'new hosts'. For 'old' hosts, he connection will fail, and needs to be reestablished. Exit / entrance selection is also an issue. One approach is to only advertise the = preferred address in the DNS if you have a primary / backup scenario. And in a 1 + = 1 scenario, then advertise both. On the outgoing the solution may be a = local server to assist, or to document preferences in the routers. We appear = to be able to design solutions that require changes to the IPv6 standards, = do no require address rewriting at exit points, but it could work, Pekka Nikkander: New hosts can use MIPv6 or SCTP. IN MIPv6 don't you = need to change both ends? CH: The support for the connected node in MIPv6 is supposed to be implemented everywhere. PN: You need to change the address in both ends. CH: The time appears to be around 5 or 6 minutes. PN: If you are going to change the code at both ends then you should try HIP in your experiments as well. CH: You are free to experiment with HIP Fujikawa: It seems like an application cannot select different path from other applications in a host? CH: No, not so. The host has several IPv6 addresses. An application that want to do path selection can bind to a source address and connect to a destination and select a path. Matasaka Ohta: It is stupid to keep using a complication MIPv6 CH: Complexity is management of the Home agent and security functions to certain classes of attacks and you will need to have some form of = security in any case. Matasaka Ohta: This only works in a single link case. In a larger site the problem is ingress filtering, because its harder = to do source-based routing. The simple solution is to work with the ISP to lift source filters. Even larger sites have their own PI space and AS#. IvB: Disable ingress filtering can be down for the local upstream, but = the chain may extend upward CH: ingress filtering in the middle of the Internet is a bad idea MO: what will you do with a large site? CH: lets call them medium Bob Hinden: ISPs would be more amenable to break ingress filtering than route specifics. ?: Ingress filtering should not be an issues. Mat Ford: Define a large site? CH: establish a registry relationship! - - draft-savola-multi6-asn-pi-00.txt, Pekka Savola, 10 min Claimed that this is not the best solution in all cases, but better = than some others. Need to avoid the routing mess of advertising more specific and need solutions soon. Approach to use the AS number to create PI = space for larger enterprises. e.g. 2000:::/32. Issues about 16 / 32 bit = AS numbers, and a claim that 32 bit AS numbers would indicate a RIR policy failure. Moshens VC(?): How do you get uniqueness of the prefix PS: This is 2000 - it won't collide! MO: There are already too many ASes deployed Geoff Huston: You are assuming AS remain at 16bits. What happens when AS drain in 2011. and we move to 32 bit AS numbers? This is a relatively = short term solution with a visible drop dead point - right? PV: yes. ?: This is good solution PV: an appendix shows how to deal with 32 bit AS numbers, but I don't = lkike this solution. Tim Chen: This cuts out the smaller sites that do not have ASs. Randy Bush: Why reluctant to give out ASes to routing domains who's = policy domains are different from their neighbors? - - draft-van-beijnum-multi6-isp-int-aggr-01.txt, Iljitsch van Beijnum, 15 min Geographical aggregation. Admitted that topology is not correlated to geography, and even if the geo part doesn't work there are still some = savings. MH: This gives little actual aggregation ?: Asymmetrical routes break in your model IvB: Routing is asymmetrical in multi-homing in any case. Tony Hain: Aggregatibility is the question. The concept appears fine, = but you are making assumptions about aggregation boundaries here. From owner-multi6@ops.ietf.org Tue Jul 15 04:45:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05611 for ; Tue, 15 Jul 2003 04:45:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cLQR-000PHW-3H for multi6-data@psg.com; Tue, 15 Jul 2003 08:44:43 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.14) id 19cLQM-000PHJ-IU for multi6@ops.ietf.org; Tue, 15 Jul 2003 08:44:38 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA16014 for ; Tue, 15 Jul 2003 09:44:36 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id JAA05862 for ; Tue, 15 Jul 2003 09:44:36 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6F8ia219936 for multi6@ops.ietf.org; Tue, 15 Jul 2003 09:44:36 +0100 Date: Tue, 15 Jul 2003 09:44:36 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: yesterday Message-ID: <20030715084436.GP18608@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, I think an important message we saw from the multi6 session was that we can do a great deal now for small/medium networks, including the interesting SOHO case, with Christian's approach. This is well-grounded practical technology that we can work on, trial and use now. The more feedback we get on this from real deployment, the better :) I agree NAROS++ could help add to Christian's proposal for sites that may wish to manage their host-based policy (as Craig has requested in the past). It is perhaps a distraction though for Christian's basic proposal, which can probably fly as it stands. In the short term it appears we need to meet demand for multihoming in "large" enterprises by bending the allocation rules, for /48's or /32's, such that big enterprises may get a SubTLA or /48. However it is not clear what sort of demand there is out there right now for this, and thus how big a swamp we would create. [Regarding the ASN method to allocate prefixes, could we simply state that only networks with ASNs as of qualify?] In the longer term the identity-location split appears most interesting. We have some good proposals in that area, e.g. from HIP and Pekka N's work. Perhaps we should think about multi6 rechartering to match whatever general path we wish to take? But that's the discussion for Wednesday morning :) Thanks to Kurtis for a nicely chaired meeting. Tim On Tue, Jul 15, 2003 at 10:18:33AM +0200, Iljitsch van Beijnum wrote: > Some random thoughts on the session yesterday: > > I once again want to object to the idea of putting a full routing table > in each host, as suggested by Masataka Ohta. I see a lot of practical > problems with this, I'm almost certain we need to create more or less a > completely new protocol for this to work as the only protocol that has > the right information is BGP but BGP needs manual configuration and > that is NOT something you want to do for each host. Then there is the > unnecessary resource consumption (IPv4 table using Zebra costs at least > 60 MB, a third of which is kernel memory wich can't be swapped out). > But the more fundamental problem is that all the really good stuff is > aggregated away in the global routing table, so the info you can derive > from that is by far inferior to what you can get from talking to the > other side. I don't mean _asking_ the other side, I mean doing > measurements on the packets going back and forth, the same way TCP does > to arrive at good round trip times. > > Also, the NAROS approach gives nodes access to info in the routing > table too without many of the drawbacks. Although I hope NAROS does > more than just look at BGP or it has the same problem. But that > shouldn't be a problem: a NAROS server could also look at the line > utilization for different connections and do traffic engineering. Some > other thoughts on NAROS: > > - Timeouts are bad. They are always too long or too short. An > additional way to handle invalidating caches in hosts would be to send > out a multicast message for this. This way, the NAROS server can > invalidate all caches and maybe even trigger rehoming of existing > sessions when something significant happens to external connectivity. > > - Probably controversial: why first do a name lookup and then a NAROS > lookup? NAROS could be a superset of DNS so a host could ask the NAROS > server for info on a FQDN and get everything it would normally get from > a DNS server and then the address preference info. This is just an > optimization of the lookup process, I'm not proposing any changes to > the the DNS here. > > - Hosts could send information they discover over the course of a > session back to the NAROS server so that it can help other hosts. For > instance, if a correspondent host has two addresses and the NAROS > server doesn't have a strong feeling about which is better, and one > doesn't work, the host sends back "this address didn't work" and then > the server can lower the priority for this address so the next host > will try the other address first. > > I think NAROS has the potential to be a very powerful tool, which means > it propably needs to be "bigger" than the author(s) originally > anticipated. It would be a shame to standardize this in a way that soon > becomes too constricting for what people actually want to do. > > On the 16 bit AS == PI prefix thing: this is just plain a very bad > idea. In the first place, it doesn't scale. Second, it WILL create a > land rush as it's very easy to get an AS number (hi Michel). Third, > current practice is already that the people with enough money that > really want it can get their own prefix, so there is no need to > specifically address this small group. > > I did like a lot of the end-to-end, host centric and so on stuff, > however, it seems to me that a lot of this doesn't include the latest > wisdom on this subject. For instance, some form of 8+8 came up but > there was no explanation about how this can work with > autoconfiguration, how badly it breaks transport protocols and so on. > > Also, some mechanisms (such as SCTP) need API changes. I think this is > EXTREMELY dangerous as this is a huge stumbling block for IPv6 > adoption. The latest OSes support IPv6 and getting a tunnel or 6to4 is > fairly trivial, but we the reason why there is very little IPv6 > adoption is that the applications simply fail to use it when it's > available. This is something we absolutely can't have with multihoming, > in my not so humble opinion. > From owner-multi6@ops.ietf.org Tue Jul 15 05:00:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06883 for ; Tue, 15 Jul 2003 05:00:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cLei-0000FK-FT for multi6-data@psg.com; Tue, 15 Jul 2003 08:59:28 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19cLee-0000Dm-VQ for multi6@ops.ietf.org; Tue, 15 Jul 2003 08:59:25 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6F8xuxS027453; Tue, 15 Jul 2003 10:59:56 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 15 Jul 2003 10:59:14 +0200 Subject: Re: yesterday Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Iljitsch van Beijnum In-Reply-To: Message-Id: <9BF99D20-B6A2-11D7-BEAB-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On dinsdag, jul 15, 2003, at 10:39 Europe/Amsterdam, Kurt Erik Lindqvist wrote: >> Also, some mechanisms (such as SCTP) need API changes. I think this is >> EXTREMELY dangerous as this is a huge stumbling block for IPv6 >> adoption. The latest OSes support IPv6 and getting a tunnel or 6to4 is >> fairly trivial, but we the reason why there is very little IPv6 >> adoption is that the applications simply fail to use it when it's >> available. This is something we absolutely can't have with >> multihoming, in my not so humble opinion. > I think this brings up the issues from the IAB meeting yesterday, what > do we want to change when. Ok, my position is: we don't want to change the API right here, right now. The cost/benefit ratio for doing this just for multihoming is out of whack. Don't forget that if the multihoming solution we come up with isn't attractive enough, people will simply push for PI in IPv6. > That we need to change large parts at some > point, I think is clear. Question is if this will really influence IPv6 > adoption or not (if the change takes us 10+ years - after we have > consensus, is it really an issue). And what we do in the mean time. It > will be interesting to see what the IAB comes up with. > I personally think that Brians presentation from yesterdays IAB meeting > was very good and pointed to the problems. And the problems with the > solutions. Yes, this was a quite disheartening list. Is it online somewhere, BTW? I think what we need is a complete overhaul of the IP architecture. We are doing so many things that go completely against the original IP assumptions, that it is amazing IP keeps working to a useful level at all. And the socket API is high on the list of stuff that's ready for retirement. But this is much more fundamental than adding multihoming to IPv6, even though that problem is somewhat fundamental also. From owner-multi6@ops.ietf.org Tue Jul 15 05:16:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08293 for ; Tue, 15 Jul 2003 05:16:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cLuJ-000162-Un for multi6-data@psg.com; Tue, 15 Jul 2003 09:15:35 +0000 Received: from [2001:360::4] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.14) id 19cLuC-00014g-Vd for multi6@ops.ietf.org; Tue, 15 Jul 2003 09:15:29 +0000 Received: from gih505.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h6F9EoQD040430; Tue, 15 Jul 2003 19:15:05 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20030715191150.01d72170@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Jul 2003 19:12:20 +1000 To: "Christian Huitema" , "Kurt Erik Lindqvist" , From: Geoff Huston Subject: RE: IETF 57 Multu6 WG - Monday morning session - minutes In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk stream of conciousness typing is not always accurate - I'll correct this Geoff At 01:40 AM 15/07/2003 -0700, Christian Huitema wrote: >Geoff, > >Thanks for the notes. You made a slight typo in the reporting of my talk, >when you wrote "We appear to >be able to design solutions that require changes to the IPv6 standards, do >no require address rewriting at exit points, but it could work". What I >said was, "We appear to >be able to design solutions that ^do not* require changes to the IPv6 >standards, do >not require address rewriting at exit points, and could work." > >There is also a small typo in a response to Pekka. You wrote: > >PN: You need to change the address in both ends. >CH: The time appears to be around 5 or 6 minutes. > > >The actual question was "you need to change code at both ends" (as >Marcello explained, you need to do something to some MIPv6 timers to be >more efficient). The response was, "You don't need to change code if you >are satisfied with the default timers, which appears to be around 5 or 6 >minutes." > >-- Christian Huitema > > > > >________________________________ > >From: owner-multi6@ops.ietf.org on behalf of Geoff Huston >Sent: Mon 7/14/2003 10:02 AM >To: Kurt Erik Lindqvist; multi6@ops.ietf.org >Cc: proceedings@ietf.org >Subject: IETF 57 Multu6 WG - Monday morning session - minutes > > > >Multi 6 Monday 1300 - 1500 > >Agenda - overview of submitted drafts > >Agenda bashing: none > > >- - draft-nikander-hip-mm-00.txt, Pekka Nikkander, 5 min > > > For background: > draft-moskowitz-hip-arch-03.txt > draft-moskowitz-hip-07.txt > > Host Identity Protocol (HIP) has been around for some time. New >namespace protocol with a history of around 4 years. Today sockets are >bound to IP addresses, forcing the IP address into a dual role of endpoint >identifiers and forwarding identifiers. HIP introduces a new namespace >between the network and transport layers. The sockets are bound to host >identifiers that are dynamically bound to IP addresses. Hosts are >identified with public keys, not IP addresses, and apps see only the HIP >identifiers. The apps need not change is the assertion. Hosts can easily >have both IPv4 and IPv6 addresses, and the assertion is that end-host >multi-homing and mobility is trivial. HIP Proxies are described as a kind >of a hack. HIP may be a part of the multi-homing architecture. 4 >Interoperating implementations, intend to send the drafts to the IESG, and >more work is needed on mobility and multi-homings with NAT traversal. HIP >is not a working group but is progressing in the background. HIP is a >multi-address solution with end-to-end. It solves only one aspect of >multi6, and has no specific solns for address selection or TE > >Matsataka Ohta: You said "HIP Proxy" - do you support multi-proxies for backup >Pekka Nikkander: There is no easy way to have multi HIP proxies in some >situations, and it does represent a single point of failure > > > >- - draft-coene-sctp-multihome-04.txt, Lode Coene, 15 min > > > SCTP approach - endpoints have multiple addresses, where each IP address >represents a path to a particular endpoint. SCTP is not aware of the level >of path distinguishing - it would be good if they were, but this is not a >known property. SCTP can detect path up/down. (Example of host-to-host with >2 addrs on each host). Multi-homing open up new horizons for SCTP: add and >remove ip addresses dynamically to the endpoint, that can support mobility. >Functionality at the endpoint is asserted to be superior to network >functions in this regards. It does imply that the host requires a routing >table - not a big deal for a host is the claim. But a big table is required >for a system with a large connection load. How to maintain the routing >table is claimed to be implementation dependant (pre-configured or caching >the INIT). NATs are in the draft because they wanted to warn everyone how >bad NATs really are! NAT cases for SCTP generates problems that do no >appear to have straightforward solutions. From the transport level SCTP is >claimed to be a 'should work' solution. > >Lixia Zhang: How about UDP? >Lode Coene: its the same problem, with the application having to undertake >the selection. >Erik Nordmark: what algorithms have been used in SCTP work to select source >and destinations? Any write ups of this work? >Lode Coene: none known to me. > > > >- - draft-bagnulo-multi6-mnm-00.txt, Marcelo Bagnulo, 10 min > > Proposes to use MIPv6 to the multi-homing (mh) problem. Example in >presentation of recovery from current to backup path (Using alternate >addresses) Both paths have to be bound and identified _before_ an outage >using binding update messages. The alternate binding will use the Home >Address Option. Since MIP already needs the exchange of messages along each >path, this exchange can be used as a path keepalive. The lifetime of the >binding is limited to 7 minutes, and this is considered to be very short. >Possible solutions are proposed > >Matsataka Ohta: IPv6 has large timeouts for various purposes. If your >proposal to have the same property so that the new address can be used >quickly. >Marcelo Bagnulo: this issue is to build a path outage detection, and we are >proposed to use the packet exchange for this purpose. The idea is to use >the same packet format, but change the timing. > > >- - draft-ohta-e2e-multihoming-05.txt, Masataka Ohta, 20 min > > General introduction on IP and IPv6. References 8+8 Locator and endpoint >I-D. The proposal is to let end systems have multiple addresses. Let the >other end select the 'best' address. (The host addresses are part of >multiple upstream aggregates). The general architecture proposed is to let >the network inform the host about state to allow the hosts to undertake >address selection. When should a host attempt alternate addresses? Proposed >in response to ICMP, routing change, timeouts (TCP only). Proposed that >applications have an IP (and UDP)-defined packet timeout to trigger >alternate address use. For very short timeouts it is proposed to send >multi-copies of the packet with multiple addresses. e-2-e mh and IP >mobility are similar, although there is mobility timing at the IP layer. >e2emh has been implemented and running on NetBSD with LIN6, with >modifications to the stack as described in the presentation. The design >framework proposed is to make everything optional. Exercising no options is >single-homed. Use 8+8 Locator/Id separation, with packet reception and >connection identification determined by the ID. Application to mobility is >also described. Multiple addresses are supplied to the peer by reverse >query of DNS using an ID query key followed by a forward query, or carry in >the TCP header or a new DNS query type. e2e approach is proposed as >scaleable architecture. MH and mobility are related, and the approach uses >8+8 separation > >Pekka Nikkander: You did not mention security issues in your presentation - >is this to be addressed later on, or do you have comments now? >Matasaka Ohta: The current Internet is weakly secure. Cookie-based security >for locator change give only the same level of security. > >Peter Werny: What is required in the DNS for this to work? >Matasaka Ohta: this is different from current V6, as it only uses the >identifier 8 bytes. In DNS we look up locators of location agents using ID >of hosts. >Peter Werny: Every host has to have a DNS entry? >Matasaka Ohta:If there is no DNS and not TCP then you are single-homed, and >you cannot use this mechanisms. >PW: Your draft has no mention of DNS update >Matasaka Ohta: Location is not in the DNS - just the location agent. >Erik Nordmark: Are you assuming a structure for the identifiers? >Matasaka Ohta: It should be reverse lookup-able. Its better to have >hierarchy in the identifier space, but you can do without hierarchy if you >use TCP instead of the DNS to pass the multiple addresses > > > >- - draft-ohira-assign-select-e2e-multihome-00.txt, FUJIKAWA Kenji, 5 min > > Each end application can determine a route to use. Applications select a >route using a selection of a specific source and destination address pair. >An end application can select a path without full route information is the >claim. The attributes are claimed to include redundancy and load balancing. >Modifications to hosts, routers and routing protocols is needed. Site exit >router selection using source address routing enables redundancy, load >sharing with multiple paths. Some mechanisms is needed for 'proper' source >address selection. Transport layer survivability could be an SCTP mechanism >or other. > > > >- - draft-arifumi-lin6-multihome-api-00.txt, Arifumi Matumoto, 10 min > > Socket API extensions. Propose to use application layer, rather than the >network. Uses 8+8 model. The API is for manipulation of multiple addresses >in the application. LIN6 is based on the 8+8 model. LIN6 does address >acquisition, notification, registration in a secure manner. Hosts identify >their peer and themselves using only the identifier part. e2e-mh is seen to >be an application of the LIN6 model. The trigger to switch locators is seen >to be ICMP-based using host unreachable. APIs need to manipulate locators, >to make a multi-locator-ready socket, allow API to change locators on the >fly, and acquire remote locators. The details of API changes described, in >socket(), getaddrinfo() and getsockopt()/setsocketopt(). APIs are intended >for active mh applications. UDP requires application support. Future work >is to put support in to the TCP level, so that no changes are required for >API for TCP. > > >- - draft-ohta-multihomed-isps-00.txt, Masataka Ohta, 10 min > > All hosts should have full default-free routing table. This allows >selector in host to make optimal locator choice, and know when locator is >unreachable. source address selection for ingress filtering only. The peer >will not use the source address - it will make its own selection of a >locator for the peer. Extended example of policy control and filtering. > > >Pekka Savola: Both of these drafts have been obsoleted >Matasaka Ohta: not a problem! >? (MCI): IF an NLA gets address space from 2 TLAs which does it use? >MO: If gets 2 addresses, as does its customers. The number of prefixes >cascades down. >? MCI): Scaleaility? >MO: yes, and NLA should be no more than triply homed. >Iljitsch van Beijnum: Why is the information in the routing table superior >to information you can obtain from the other end? >MO: This does not have scaleability problems if you limit connectivity. >This is a connectionless system where a host has no information about the >other end, and the routing table is local information you can use. >Iljitsch van Beijnum: ok, but I disagree with this > > > >- - draft-de-launois-multi6-naros-01.txt, Cedric de Launois, 10 min > > > Solution for traffic engineering for mh need sites in a multi-address >environment. Each host has 1 address per upstream provider. Noted that >choosing a source address implies choosing a provider (assuming providers >perform source address filtering). Which source? A host has no information >about which provider to use to reach a destination. Propose to use a >dedicated agent (server). A host will query the server with a destination >address, and the server responds with the source to use. The burden of >selecting the source address is aggregated to a dedicated server. Note it >gives only a hint to the host about what address to use. NAROS is not >intended to preserve flows across address changes. SCTP or HIP could be >used to preserve flows. The server could be anycast, or undertaken without >provider interaction. The host / server protocol is a query response packet >exchange. Where multiple choices exist, multiple parameters can be used to >make the selection. > >Pekka Nikkander: is this a new protocol, or, perhaps, ICMP >Cedric de Launois: No particular protocol - it could be ICMP >PN: There are security issues here, like secure neighbor discovery >Michael Richardson: Takes the example and adds further connections, and >then adds a policy question about 'acceptable traffic' policies. Can NAROS >deal with this> >CdL: A lot of requirements could be placed in the NAROS server and it could >be aware of those kind of requirements. >Matsataka Ohta: Anycast does not include increased robustness for server >failure. A NAROS server crash will not bring down a anycast route. Also 300 >seconds is too large a value. > > > >- - draft-huitema-multi6-hosts-02.txt, Chistian Huitema & David > Kessens, 20 min > > Simple multihoming experiment. A problem statement in a bounded example >environment. A simple network is a single link where multiple hosts see >multiple boundary routers where each router is connected to distinct >upstreams. Addresses from providers are mapped to all the hosts. Asserted >that this is not uncommon in V4 and that the common solution is to NAT the >local net and allow the NAT to 'rehome' to each outbound. The consequence >is flow breakage across the rehoming of the NAT. The bounds are that the >ISPS do not exchange information, there are provider addresses with an >assigned prefix per provider. Hosts configure an address with each prefix. >Need to resolve host choice of egress router selection (as a function of >the source address) > >Erik Nordmark: There are people talking about movement detection, and this >gets all routers to advertise all prefixes >Christian Huitema: Thats not incompatible - several routers can advertise >the same information, provided that the information is equivalent, and the >routers can handle all such packets. >Pekka Savola: please clarify the applicability. This is only the case where >hosts are directly connected to all egress routers. >Christian: this is a common case. >MO: You don't need tunnels in a single link network. In a multi-link >network you need tunnels. >CH: This does nothing for MTU discovery. For single link there is a very >simple solution and this can be extended for multi-links >MO: Ands I'm saying its impossible >CH: fine! > > No need for tunnels in a single link network, and the routers can pass >off to each other in the event of dynamic failure. The assertion is that in >a single link network this requirement can be easily met. Dead exist >routers or dead ISP require some consideration. If the exit router knows >that the path is dead it can send a poison advertisement of the prefix. The >real issue with this form of mh is a very soft definition of 'broken' where >the link may be up, but the path to the remote end point may be unuseable. >This kind of problem is an e2e detection issue. Hosts may need to keep >track of connections and track quality. If you know an ingress path is dead >do you need to update the DNS to remove the dead prefix from your host >entry? Of course you may not know and in this case your peer will need to >work out what address to use. Maintenance of TCP connections is an issue. >MIP6 may be an answer, or SCTP for 'new hosts'. For 'old' hosts, he >connection will fail, and needs to be reestablished. Exit / entrance >selection is also an issue. One approach is to only advertise the preferred >address in the DNS if you have a primary / backup scenario. And in a 1 + 1 >scenario, then advertise both. On the outgoing the solution may be a local >server to assist, or to document preferences in the routers. We appear to >be able to design solutions that require changes to the IPv6 standards, do >no require address rewriting at exit points, but it could work, > >Pekka Nikkander: New hosts can use MIPv6 or SCTP. IN MIPv6 don't you need >to change both ends? >CH: The support for the connected node in MIPv6 is supposed to be >implemented everywhere. >PN: You need to change the address in both ends. >CH: The time appears to be around 5 or 6 minutes. >PN: If you are going to change the code at both ends then you should try >HIP in your experiments as well. >CH: You are free to experiment with HIP >Fujikawa: It seems like an application cannot select different path from >other applications in a host? >CH: No, not so. The host has several IPv6 addresses. An application that >want to do path selection can bind to a source address and connect to a >destination and select a path. >Matasaka Ohta: It is stupid to keep using a complication MIPv6 >CH: Complexity is management of the Home agent and security functions to >certain classes of attacks and you will need to have some form of security >in any case. >Matasaka Ohta: This only works in a single link case. > > In a larger site the problem is ingress filtering, because its harder to >do source-based routing. The simple solution is to work with the ISP to >lift source filters. Even larger sites have their own PI space and AS#. > >IvB: Disable ingress filtering can be down for the local upstream, but the >chain may extend upward >CH: ingress filtering in the middle of the Internet is a bad idea >MO: what will you do with a large site? >CH: lets call them medium >Bob Hinden: ISPs would be more amenable to break ingress filtering than >route specifics. >?: Ingress filtering should not be an issues. >Mat Ford: Define a large site? >CH: establish a registry relationship! > > >- - draft-savola-multi6-asn-pi-00.txt, Pekka Savola, 10 min > > > Claimed that this is not the best solution in all cases, but better than >some others. Need to avoid the routing mess of advertising more specific >and need solutions soon. Approach to use the AS number to create PI space >for larger enterprises. e.g. 2000:::/32. Issues about 16 / 32 bit AS >numbers, and a claim that 32 bit AS numbers would indicate a RIR policy >failure. > > > >Moshens VC(?): How do you get uniqueness of the prefix >PS: This is 2000 - it won't collide! >MO: There are already too many ASes deployed >Geoff Huston: You are assuming AS remain at 16bits. What happens when AS >drain in 2011. and we move to 32 bit AS numbers? This is a relatively short >term solution with a visible drop dead point - right? >PV: yes. >?: This is good solution >PV: an appendix shows how to deal with 32 bit AS numbers, but I don't lkike >this solution. >Tim Chen: This cuts out the smaller sites that do not have ASs. >Randy Bush: Why reluctant to give out ASes to routing domains who's policy >domains are different from their neighbors? > > >- - draft-van-beijnum-multi6-isp-int-aggr-01.txt, Iljitsch van Beijnum, > 15 min > > > Geographical aggregation. Admitted that topology is not correlated to >geography, and even if the geo part doesn't work there are still some savings. > >MH: This gives little actual aggregation >?: Asymmetrical routes break in your model >IvB: Routing is asymmetrical in multi-homing in any case. >Tony Hain: Aggregatibility is the question. The concept appears fine, but >you are making assumptions about aggregation boundaries here. From owner-multi6@ops.ietf.org Tue Jul 15 05:22:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09010 for ; Tue, 15 Jul 2003 05:22:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cM0q-0001PI-QH for multi6-data@psg.com; Tue, 15 Jul 2003 09:22:20 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19cM0o-0001OA-Ux for multi6@ops.ietf.org; Tue, 15 Jul 2003 09:22:18 +0000 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Jul 2003 02:21:48 -0700 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 15 Jul 2003 02:21:48 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 02:21:48 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 02:21:47 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 02:21:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.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: yesterday Date: Tue, 15 Jul 2003 02:21:46 -0700 Message-ID: Thread-Topic: yesterday Thread-Index: AcNKr/szn6z44Dl0S4+g8/mzZcnp/AAAXWpa From: "Christian Huitema" To: "Iljitsch van Beijnum" , "Kurt Erik Lindqvist" Cc: X-OriginalArrivalTime: 15 Jul 2003 09:21:47.0423 (UTC) FILETIME=[83E912F0:01C34AB2] X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I am a bit puzzled when we present SCTP as a generic solution, or say = things like "adopting SCTP would require an API change". SCTP is a = transport protocol, just like TCP and UDP. It fills different needs than = TCP or UDP, and is arguably a good match for some applications. The = issue of whether an application uses SCTP, or TCP, or UDP, is driven by = the application's requirements, not by the use of multi-homing. Lode's = presentation explained how SCTP can be used to take advantage of the = multi-addressing variants of site multi-homing, which is good news for = the SCTP based applications. But we still need to make sure that = applications based on TCP or UDP also work well. =20 -- Christian Huitema From owner-multi6@ops.ietf.org Tue Jul 15 05:26:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09446 for ; Tue, 15 Jul 2003 05:26:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cM4M-0001cn-J5 for multi6-data@psg.com; Tue, 15 Jul 2003 09:25:58 +0000 Received: from [81.160.16.8] (helo=smtp.ietf57.telekom.at) by psg.com with esmtp (Exim 4.14) id 19cM4I-0001aN-6G for multi6@ops.ietf.org; Tue, 15 Jul 2003 09:25:54 +0000 Received: from info.ucl.ac.be ([81.160.183.138]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6F9PHk02738; Tue, 15 Jul 2003 11:25:17 +0200 (MEST) Message-ID: <3F13C80A.6090903@info.ucl.ac.be> Date: Tue, 15 Jul 2003 11:23:22 +0200 From: Cedric de Launois User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: multi6@ops.ietf.org Subject: Re: yesterday References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-38.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Iljitsch van Beijnum wrote: > Some random thoughts on the session yesterday: > > I once again want to object to the idea of putting a full routing > table in each host, as suggested by Masataka Ohta. I see a lot of > practical problems with this, I'm almost certain we need to create > more or less a completely new protocol for this to work as the only > protocol that has the right information is BGP but BGP needs manual > configuration and that is NOT something you want to do for each host. > Then there is the unnecessary resource consumption (IPv4 table using > Zebra costs at least 60 MB, a third of which is kernel memory wich > can't be swapped out). But the more fundamental problem is that all > the really good stuff is aggregated away in the global routing table, > so the info you can derive from that is by far inferior to what you > can get from talking to the other side. I don't mean _asking_ the > other side, I mean doing measurements on the packets going back and > forth, the same way TCP does to arrive at good round trip times. Agreed. I think that putting all the informations in the end-hosts would imply an unacceptable waste of resources. Moreover, to best take advantage from the BGP routing system, we should get access not to only one BGP table but to _all_ the BGP tables of the providers. This is clearly unacceptable to put in all the end hosts. > > Also, the NAROS approach gives nodes access to info in the routing > table too without many of the drawbacks. Although I hope NAROS does > more than just look at BGP or it has the same problem. But that > shouldn't be a problem: a NAROS server could also look at the line > utilization for different connections and do traffic engineering. Some > other thoughts on NAROS: Of course. NAROS is not limited to just looking at BGP. It can monitor the exit links, check their correct utilization, and change accordingly the way it proposes the best addresses. > - Timeouts are bad. They are always too long or too short. An > additional way to handle invalidating caches in hosts would be to send > out a multicast message for this. This way, the NAROS server can > invalidate all caches and maybe even trigger rehoming of existing > sessions when something significant happens to external connectivity. The 300s lifetime was just an example. We performed simulations that show that this timeout is reasonable to get good traffic engineering capabilities for a site with ~7500 hosts without putting to much load on the NAROS server (its load average was ~35 req/s). Of course this does not mean that this timeout is always the best one. This is always a trade-off between the server load and the traffic engineering quality. Maybe the use of a multicast message to invalidate the cache would be useful. I'm open to any suggestion. But remember that the detection of connectivity loss can also be detected by the end-host, and probably faster than by the NAROS server. The goal of the lifetime is only to reduce the number of NAROS requests to send. Just think about a host that loads an web page : the host will probably open several connections in a short period. Without lifetimes, the NAROS load would be rapidly unacceptable. > - Probably controversial: why first do a name lookup and then a NAROS > lookup? NAROS could be a superset of DNS so a host could ask the NAROS > server for info on a FQDN and get everything it would normally get > from a DNS server and then the address preference info. This is just > an optimization of the lookup process, I'm not proposing any changes > to the the DNS here. Hehe, we already thought about this kind of stuff. NAROS means : _NAME_ Address and ROute Server. This is an optimization but it would be interesting to go that way. > - Hosts could send information they discover over the course of a > session back to the NAROS server so that it can help other hosts. For > instance, if a correspondent host has two addresses and the NAROS > server doesn't have a strong feeling about which is better, and one > doesn't work, the host sends back "this address didn't work" and then > the server can lower the priority for this address so the next host > will try the other address first. This sounds good for me. > I think NAROS has the potential to be a very powerful tool, which > means it propably needs to be "bigger" than the author(s) originally > anticipated. It would be a shame to standardize this in a way that > soon becomes too constricting for what people actually want to do. Agree. This proposition is far to young to be standardized and needs to be stronger/bigger. Some of our ideas were not written in the draft in order to make this proposition as open as possible. I'm happy that Iljitsch come to the same conclusions and ideas than me. Cédric From owner-multi6@ops.ietf.org Tue Jul 15 05:28:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09709 for ; Tue, 15 Jul 2003 05:28:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cM6p-0001nv-1E for multi6-data@psg.com; Tue, 15 Jul 2003 09:28:31 +0000 Received: from [194.196.100.238] (helo=d12lmsgate-5.de.ibm.com) by psg.com with esmtp (Exim 4.14) id 19cM6m-0001lB-Lf for multi6@ops.ietf.org; Tue, 15 Jul 2003 09:28:28 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6F9Rfu5029542; Tue, 15 Jul 2003 11:27:41 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6F9RdQs139822; Tue, 15 Jul 2003 11:27:40 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA32352; Tue, 15 Jul 2003 11:27:36 +0200 Message-ID: <3F13C910.78375655@hursley.ibm.com> Date: Tue, 15 Jul 2003 11:27:44 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: Re: yesterday References: <9BF99D20-B6A2-11D7-BEAB-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-12.8 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: ... > > I personally think that Brians presentation from yesterdays IAB meeting > > was very good and pointed to the problems. And the problems with the > > solutions. > > Yes, this was a quite disheartening list. Is it online somewhere, BTW? It will show up in due course somewhere. If anyone has a handy server, I will supply a PDF. Brian From owner-multi6@ops.ietf.org Tue Jul 15 05:53:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11423 for ; Tue, 15 Jul 2003 05:53:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cMUW-0003Tw-Qj for multi6-data@psg.com; Tue, 15 Jul 2003 09:53:00 +0000 Received: from [81.160.235.37] (helo=laptop2.ietf57.telekom.at) by psg.com with esmtp (Exim 4.14) id 19cMUU-0003Tj-Fv for multi6@ops.ietf.org; Tue, 15 Jul 2003 09:52:58 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.ietf57.telekom.at (8.12.9/8.10.2) with ESMTP id h6F9qvk1000459; Tue, 15 Jul 2003 11:52:57 +0200 (CEST) Date: Tue, 15 Jul 2003 11:52:52 +0200 Subject: Re: yesterday Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Iljitsch van Beijnum , multi6@ops.ietf.org To: Brian E Carpenter From: Kurt Erik Lindqvist In-Reply-To: <3F13C910.78375655@hursley.ibm.com> Message-Id: <199CE604-B6AA-11D7-A9AB-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.2 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, UPPERCASE_25_50,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> I personally think that Brians presentation from yesterdays IAB >>> meeting >>> was very good and pointed to the problems. And the problems with the >>> solutions. >> >> Yes, this was a quite disheartening list. Is it online somewhere, BTW? > > It will show up in due course somewhere. If anyone has a handy server, > I will supply a PDF. > I will create a web-page for the multi6 presentations, I can put it there if you want to. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPxPO+KarNKXTPFCVEQKJcACgo916sd+GoHiFJWy1kO6XgKf3Gv4AnRiK mwIhz5zNk6jq1JmEXPfoGUJa =KAb8 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jul 15 07:30:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14662 for ; Tue, 15 Jul 2003 07:30:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cNzP-0008on-J2 for multi6-data@psg.com; Tue, 15 Jul 2003 11:28:59 +0000 Received: from [2001:360::4] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.14) id 19cNzH-0008nd-8E for multi6@ops.ietf.org; Tue, 15 Jul 2003 11:28:51 +0000 Received: from gih505.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h6FBR7QE040968; Tue, 15 Jul 2003 21:27:21 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20030715211811.02207578@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Jul 2003 21:26:32 +1000 To: kurtis@kurtis.pp.se, multi6@ops.ietf.org From: Geoff Huston Subject: Re: IETF 57 Multu6 WG - Monday morning session - minutes Cc: proceedings@ietf.org In-Reply-To: References: <5.1.0.14.2.20030715025859.01bd45f8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_00,IN_REP_TO,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Thank you to Iljitsch and Christian for your corrections. Heres (what I hope to be the final version of) the minutes of Monday's multi6 wg minutes Geoff ---------------------- Multi 6 Monday 1300 - 1500 Agenda - overview of submitted drafts Agenda bashing: none - - draft-nikander-hip-mm-00.txt, Pekka Nikkander, 5 min For background: draft-moskowitz-hip-arch-03.txt draft-moskowitz-hip-07.txt Host Identity Protocol (HIP) has been around for some time. New namespace protocol with a history of around 4 years. Today sockets are bound to IP addresses, forcing the IP address into a dual role of endpoint identifiers and forwarding identifiers. HIP introduces a new namespace between the network and transport layers. The sockets are bound to host identifiers that are dynamically bound to IP addresses. Hosts are identified with public keys, not IP addresses, and apps see only the HIP identifiers. The apps need not change is the assertion. Hosts can easily have both IPv4 and IPv6 addresses, and the assertion is that end-host multi-homing and mobility is trivial. HIP Proxies are described as a kind of a hack. HIP may be a part of the multi-homing architecture. 4 Interoperating implementations, intend to send the drafts to the IESG, and more work is needed on mobility and multi- homing with NAT traversal. HIP is not a working group but is progressing in the background. HIP is a multi-address solution with end- to-end. It solves only one aspect of multi6, and has no specific solutions for address selection or TE Matsataka Ohta: You said "HIP Proxy" - do you support multi-proxies for backup Pekka Nikkander: There is no easy way to have multi HIP proxies in some situations, and it does represent a single point of failure - - draft-coene-sctp-multihome-04.txt, Lode Coene, 15 min SCTP approach - endpoints have multiple addresses, where each IP address represents a path to a particular endpoint. SCTP is not aware of the level of path distinguishing - it would be good if they were, but this is not a known property. SCTP can detect path up/down. (Example of host- to-host with 2 addresses on each host). Multi-homing open up new horizons for SCTP: add and remove IP addresses dynamically to the endpoint, that can support mobility. Functionality at the endpoint is asserted to be superior to network functions in this regards. It does imply that the host requires a routing table - not a big deal for a host is the claim. But a big table is required for a system with a large connection load. How to maintain the routing table is claimed to be implementation dependant (pre-configured or caching the INIT). NATs are in the draft because they wanted to warn everyone how bad NATs really are! NAT cases for SCTP generates problems that do no appear to have straightforward solutions. From the transport level SCTP is claimed to be a 'should work' solution. Lixia Zhang: How about UDP? Lode Coene: its the same problem, with the application having to undertake the selection. Erik Nordmark: what algorithms have been used in SCTP work to select source and destinations? Any write ups of this work? Lode Coene: none known to me. - - draft-bagnulo-multi6-mnm-00.txt, Marcelo Bagnulo, 10 min Proposes to use MIPv6 to the multi-homing (mh) problem. Example in presentation of recovery from current to backup path (Using alternate addresses) Both paths have to be bound and identified _before_ an outage using binding update messages. The alternate binding will use the Home Address Option. Since MIP already needs the exchange of messages along each path, this exchange can be used as a path keepalive. The lifetime of the binding is limited to 7 minutes, and this is considered to be very short. Possible solutions are proposed Matsataka Ohta: IPv6 has large timeouts for various purposes. If your proposal to have the same property so that the new address can be used quickly. Marcelo Bagnulo: this issue is to build a path outage detection, and we are proposed to use the packet exchange for this purpose. The idea is to use the same packet format, but change the timing. - - draft-ohta-e2e-multihoming-05.txt, Masataka Ohta, 20 min General introduction on IP and IPv6. References 8+8 Locator and endpoint I-D. The proposal is to let end systems have multiple addresses. Let the other end select the 'best' address. (The host addresses are part of multiple upstream aggregates). The general architecture proposed is to let the network inform the host about state to allow the hosts to undertake address selection. When should a host attempt alternate addresses? Proposed in response to ICMP, routing change, timeouts (TCP only). Proposed that applications have an IP (and UDP)-defined packet timeout to trigger alternate address use. For very short timeouts it is proposed to send multi-copies of the packet with multiple addresses. e-2-e mh and IP mobility are similar, although there is mobility timing at the IP layer. e2emh has been implemented and running on NetBSD with LIN6, with modifications to the stack as described in the presentation. The design framework proposed is to make everything optional. Exercising no options is single-homed. Use 8+8 Locator/Id separation, with packet reception and connection identification determined by the ID. Application to mobility is also described. Multiple addresses are supplied to the peer by reverse query of DNS using an ID query key followed by a forward query, or carry in the TCP header or a new DNS query type. e2e approach is proposed as scaleable architecture. MH and mobility are related, and the approach uses 8+8 separation Pekka Nikkander: You did not mention security issues in your presentation - is this to be addressed later on, or do you have comments now? Matasaka Ohta: The current Internet is weakly secure. Cookie-based security for locator change give only the same level of security. Peter Werny: What is required in the DNS for this to work? Matasaka Ohta: this is different from current V6, as it only uses the identifier 8 bytes. In DNS we look up locators of location agents using ID of hosts. Peter Werny: Every host has to have a DNS entry? Matasaka Ohta:If there is no DNS and not TCP then you are single-homed, and you cannot use this mechanisms. PW: Your draft has no mention of DNS update Matasaka Ohta: Location is not in the DNS - just the location agent. Erik Nordmark: Are you assuming a structure for the identifiers? Matasaka Ohta: It should be reverse lookup-able. Its better to have hierarchy in the identifier space, but you can do without hierarchy if you use TCP instead of the DNS to pass the multiple addresses - - draft-ohira-assign-select-e2e-multihome-00.txt, FUJIKAWA Kenji, 5 min Each end application can determine a route to use. Applications select a route using a selection of a specific source and destination address pair. An end application can select a path without full route information is the claim. The attributes are claimed to include redundancy and load balancing. Modifications to hosts, routers and routing protocols is needed. Site exit router selection using source address routing enables redundancy, load sharing with multiple paths. Some mechanisms is needed for 'proper' source address selection. Transport layer survivability could be an SCTP mechanism or other. - - draft-arifumi-lin6-multihome-api-00.txt, Arifumi Matumoto, 10 min Socket API extensions. Propose to use application layer, rather than the network. Uses 8+8 model. The API is for manipulation of multiple addresses in the application. LIN6 is based on the 8+8 model. LIN6 does address acquisition, notification, registration in a secure manner. Hosts identify their peer and themselves using only the identifier part. e2e-mh is seen to be an application of the LIN6 model. The trigger to switch locators is seen to be ICMP-based using host unreachable. APIs need to manipulate locators, to make a multi-locator-ready socket, allow API to change locators on the fly, and acquire remote locators. The details of API changes described, in socket(), getaddrinfo() and getsockopt()/setsocketopt(). APIs are intended for active mh applications. UDP requires application support. Future work is to put support in to the TCP level, so that no changes are required for API for TCP. - - draft-ohta-multihomed-isps-00.txt, Masataka Ohta, 10 min All hosts should have full default-free routing table. This allows selector in host to make optimal locator choice, and know when locator is unreachable. source address selection for ingress filtering only. The peer will not use the source address - it will make its own selection of a locator for the peer. Extended example of policy control and filtering. Pekka Savola: Both of these drafts have been obsoleted Matasaka Ohta: not a problem! ? (MCI): IF an NLA gets address space from 2 TLAs which does it use? MO: If gets 2 addresses, as does its customers. The number of prefixes cascades down. ? MCI): Scaleability? MO: yes, and NLA should be no more than triply homed. Iljitsch van Beijnum: Why is the information in the routing table superior to information you can obtain from the other end? MO: This does not have scaleability problems if you limit connectivity. This is a connectionless system where a host has no information about the other end, and the routing table is local information you can use. Iljitsch van Beijnum: ok, but I disagree with this - - draft-de-launois-multi6-naros-01.txt, Cedric de Launois, 10 min Solution for traffic engineering for mh need sites in a multi-address environment. Each host has 1 address per upstream provider. Noted that choosing a source address implies choosing a provider (assuming providers perform source address filtering). Which source? A host has no information about which provider to use to reach a destination. Propose to use a dedicated agent (server). A host will query the server with a destination address, and the server responds with the source to use. The burden of selecting the source address is aggregated to a dedicated server. Note it gives only a hint to the host about what address to use. NAROS is not intended to preserve flows across address changes. SCTP or HIP could be used to preserve flows. The server could be anycast, or undertaken without provider interaction. The host / server protocol is a query response packet exchange. Where multiple choices exist, multiple parameters can be used to make the selection. Pekka Nikkander: is this a new protocol, or, perhaps, ICMP Cedric de Launois: No particular protocol - it could be ICMP PN: There are security issues here, like secure neighbor discovery Michael Richardson: Takes the example and adds further connections, and then adds a policy question about 'acceptable traffic' policies. Can NAROS deal with this> CdL: A lot of requirements could be placed in the NAROS server and it could be aware of those kind of requirements. Matsataka Ohta: Anycast does not include increased robustness for server failure. A NAROS server crash will not bring down a anycast route. Also 300 seconds is too large a value. - - draft-huitema-multi6-hosts-02.txt, Christian Huitema & David Kessens, 20 min Simple multihoming experiment. A problem statement in a bounded example environment. A simple network is a single link where multiple hosts see multiple boundary routers where each router is connected to distinct upstreams. Addresses from providers are mapped to all the hosts. Asserted that this is not uncommon in V4 and that the common solution is to NAT the local net and allow the NAT to 'rehome' to each outbound. The consequence is flow breakage across the rehoming of the NAT. The bounds are that the ISPS do not exchange information, there are provider addresses with an assigned prefix per provider. Hosts configure an address with each prefix. Need to resolve host choice of egress router selection (as a function of the source address) Erik Nordmark: There are people talking about movement detection, and this gets all routers to advertise all prefixes Christian Huitema: That's not incompatible - several routers can advertise the same information, provided that the information is equivalent, and the routers can handle all such packets. Pekka Savola: please clarify the applicability. This is only the case where hosts are directly connected to all egress routers. Christian: this is a common case. MO: You don't need tunnels in a single link network. In a multi-link network you need tunnels. CH: This does nothing for MTU discovery. For single link there is a very simple solution and this can be extended for multi-links MO: Ands I'm saying its impossible CH: fine! No need for tunnels in a single link network, and the routers can pass off to each other in the event of dynamic failure. The assertion is that in a single link network this requirement can be easily met. Dead exist routers or dead ISP require some consideration. If the exit router knows that the path is dead it can send a poison advertisement of the prefix. The real issue with this form of mh is a very soft definition of 'broken' where the link may be up, but the path to the remote end point may be unuseable. This kind of problem is an e2e detection issue. Hosts may need to keep track of connections and track quality. If you know an ingress path is dead do you need to update the DNS to remove the dead prefix from your host entry? Of course you may not know and in this case your peer will need to work out what address to use. Maintenance of TCP connections is an issue. MIP6 may be an answer, or SCTP for 'new hosts'. For 'old' hosts, he connection will fail, and needs to be reestablished. Exit / entrance selection is also an issue. One approach is to only advertise the preferred address in the DNS if you have a primary / backup scenario. And in a 1 + 1 scenario, then advertise both. On the outgoing the solution may be a local server to assist, or to document preferences in the routers. We appear to be able to design solutions that do not require changes to the IPv6 standards, do not require address rewriting at exit points, and it could work, Pekka Nikkander: New hosts can use MIPv6 or SCTP. IN MIPv6 don't you need to change both ends? CH: The support for the connected node in MIPv6 is supposed to be implemented everywhere. PN: You need to change the code at both ends. CH: You don't need to change code if you are satisfied with the default timers, which appears to be around 5 or 6 minutes." PN: If you are going to change the code at both ends then you should try HIP in your experiments as well. CH: You are free to experiment with HIP Fujikawa: It seems like an application cannot select different path from other applications in a host? CH: No, not so. The host has several IPv6 addresses. An application that want to do path selection can bind to a source address and connect to a destination and select a path. Matasaka Ohta: It is stupid to keep using a complication MIPv6 CH: Complexity is management of the Home agent and security functions to certain classes of attacks and you will need to have some form of security in any case. Matasaka Ohta: This only works in a single link case. In a larger site the problem is ingress filtering, because its harder to do source-based routing. The simple solution is to work with the ISP to lift source filters. Even larger sites have their own PI space and AS#. IvB: Disable ingress filtering can be down for the local upstream, but the chain may extend upward CH: ingress filtering in the middle of the Internet is a bad idea MO: what will you do with a large site? CH: lets call them medium Bob Hinden: ISPs would be more amenable to break ingress filtering than route specifics. ?: Ingress filtering should not be an issues. Mat Ford: Define a large site? CH: establish a registry relationship! - - draft-savola-multi6-asn-pi-00.txt, Pekka Savola, 10 min Claimed that this is not the best solution in all cases, but better than some others. Need to avoid the routing mess of advertising more specific and need solutions soon. Approach to use the AS number to create PI space for larger enterprises. e.g. 2000:::/32. Issues about 16 / 32 bit AS numbers, and a claim that 32 bit AS numbers would indicate a RIR policy failure. Moshens VC(?): How do you get uniqueness of the prefix PS: This is 2000 - it won't collide! MO: There are already too many ASes deployed Geoff Huston: You are assuming AS remain at 16bits. What happens when AS drain in 2011. and we move to 32 bit AS numbers? This is a relatively short term solution with a visible drop dead point - right? PV: yes. ?: This is good solution PV: an appendix shows how to deal with 32 bit AS numbers, but I don't like this solution. Tim Chen: This cuts out the smaller sites that do not have ASs. Randy Bush: Why reluctant to give out ASes to routing domains who's policy domains are different from their neighbors? - - draft-van-beijnum-multi6-isp-int-aggr-01.txt, Iljitsch van Beijnum, 15 min Geographical aggregation. Admitted that topology is not correlated to geography, and even if the geo part doesn't work there are still some savings. Goal is enabling multihoming ASAP. This is a short term solution. It works by distributing the global routing table over the routers within an (ISP) network rather than giving every router a full copy as is done today. This would lead to scenic routing but the geo aspect repairs this. Unless there is insufficient interconnection between networks, then aggregation must be broken. Geographic aggregates are internal to each network and not announced externally. Correlation between topology and geography is less than 1, but also more than 0 and even without geography there are still some savings. No real downsides: RIRs must implement geographic address allocation, ISPs can implement this (or not) at their convenience. MH: This gives little actual aggregation ?: Asymmetrical routes break in your model IvB: today it's asymmetrical anyway (re hot potato routing) and when both sides do geo aggregation it is still asymmetrical, when one end is geo multihomed and the other isn't it's symmetrical. But read the draft as it has a section on exactly this issue from an ISP traffic distribution viewpoint. Tony Hain: Aggregatibility is the question. The concept appears fine, but you are making assumptions about aggregation boundaries here. IvB: Short answer: you can make your own boundaries or this can even work with your (Tony's) geographic addressing plan. Long answer: no time for the long answer... From owner-multi6@ops.ietf.org Tue Jul 15 07:39:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15087 for ; Tue, 15 Jul 2003 07:39:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cO8z-0009T0-BE for multi6-data@psg.com; Tue, 15 Jul 2003 11:38:53 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19cO8w-0009So-By for multi6@ops.ietf.org; Tue, 15 Jul 2003 11:38:50 +0000 From: Masataka Ohta Message-Id: <200307151126.UAA00700@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA00700; Tue, 15 Jul 2003 20:26:28 +0900 Subject: Re: IETF 57 Multu6 WG - Monday morning session - minutes In-Reply-To: <5.1.0.14.2.20030715025859.01bd45f8@localhost> from Geoff Huston at "Jul 15, 2003 03:02:32 am" To: Geoff Huston Date: Tue, 15 Jul 2003 20:26:27 +0859 () CC: Kurt Erik Lindqvist , multi6@ops.ietf.org, proceedings@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Geoff; > Matsataka Ohta: IPv6 has large timeouts for various purposes. If your < Matsataka Ohta: MIPv6 has large timeouts for various purposes. If your > address selection. When should a host attempt alternate addresses? Proposed > in response to ICMP, routing change, timeouts (TCP only). Proposed that > address selection. When should a host attempt alternate addresses? Proposed < in response to ICMP, routing change, timeouts (TCP, but not IP nor UDP, has a defact default). Proposed that > Pekka Nikkander: You did not mention security issues in your presentation - > is this to be addressed later on, or do you have comments now? > Matasaka Ohta: The current Internet is weakly secure. Cookie-based security > for locator change give only the same level of security. > Pekka Nikkander: You did not mention security issues in your presentation - > is this to be addressed later on, or do you have comments now? > Matasaka Ohta: The current Internet is weakly secure. Cookie-based security < for locator change give JUST the same level of security. It's overkill to use DSA signature only to confirm that random peers keep identities. > - - draft-ohta-multihomed-isps-00.txt, Masataka Ohta, 10 min > > All hosts should have full default-free routing table. This allows > selector in host to make optimal locator choice, and know when locator is > unreachable. source address selection for ingress filtering only. The peer > will not use the source address - it will make its own selection of a > locator for the peer. Extended example of policy control and filtering. > locator for the peer. Extended example of policy control and filtering. < NLAs may have as many peers as necessary and have full control on < egress policy, though there is small limitation on ingress policy < control, ingress control is limited from the beginning and is < not a problem. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jul 15 08:21:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16095 for ; Tue, 15 Jul 2003 08:21:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cOnD-000BjK-3o for multi6-data@psg.com; Tue, 15 Jul 2003 12:20:27 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19cOnA-000Bj8-F2 for multi6@ops.ietf.org; Tue, 15 Jul 2003 12:20:24 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6FCL4xS029671 for ; Tue, 15 Jul 2003 14:21:04 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 15 Jul 2003 14:20:21 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Multihoming experiment From: Iljitsch van Beijnum To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-9.7 required=5.0 tests=BAYES_01,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A few observations on Christian and David's multihoming experiment: This means source address dependent routing, but I don't think this term is used anywhere. The consequence of this is that sites that implement this CANNOT use any form of dynamic routing. Also, I'm afraid there will be traffic engineering problems because of RFC 3484 for hosts that implement this. For instance, if at some point the RIRs use up 2001::/16 and they start giving out address space from 2003::/16, a host with a 2001:: and a 2003:: address will use the router that announces the 2001:: prefix for all traffic to 2001::/16 which would be nearly all of the IPv6 internet. And note well, from RFC 3484: Well-behaved applications SHOULD iterate through the list of addresses returned from getaddrinfo() until they find a working address. Applications that don't implement this will have to wait for a prefix to become deprecated to switch to the other one, so the multihoming benefits for those applications would be even smaller. From owner-multi6@ops.ietf.org Tue Jul 15 10:55:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22832 for ; Tue, 15 Jul 2003 10:55:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRCK-000KIH-Fz for multi6-data@psg.com; Tue, 15 Jul 2003 14:54:32 +0000 Received: from [3ffe:501:100c:d120::53] (helo=shonan.sfc.wide.ad.jp) by psg.com with esmtp (Exim 4.14) id 19cRC2-000KGK-9J for multi6@ops.ietf.org; Tue, 15 Jul 2003 14:54:14 +0000 Received: from localhost.nautilus6.org (unknown [81.160.206.92]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id A6EE65D03A; Tue, 15 Jul 2003 23:53:39 +0900 (JST) Date: Tue, 15 Jul 2003 23:50:49 +0900 From: Thierry Ernst To: multi6@ops.ietf.org Cc: cwng@psl.com.sg, julien@sfc.wide.ad.jp Subject: Re: FYI draft-charbon-nemo-multihoming-evaluation-00.txt Message-Id: <20030715235049.64065525.ernst@sfc.wide.ad.jp> In-Reply-To: <20030714212236.04f372ab.julien@sfc.wide.ad.jp> References: <20030714212236.04f372ab.julien@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Tue__15_Jul_2003_23:50:49_+0900_083475a8" X-Spam-Status: No, hits=-22.5 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Multipart_Tue__15_Jul_2003_23:50:49_+0900_083475a8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dear all, Just to add based on this, we will have a slot discussing about multihoming in the NEMO session tomorrow at 18.00 pm. Your participation would be appreciated. I have attached the agenda. Comment on the 2 multihoming drafts and comments on section "multihoming" in draft-ietf-nemo-terminology-00.txt would be appreciated. Thanks, Thierry Ernst, NEMO co-chair. > We have written an Internet-Draft on the evaluation of Multi-Homing > support by NEMO Basic solution [1]. The Multi-Homing being a wide > problematic maybe some part of this document can be useful for your > information. > > You can check this draft at this URL: > > [http://www.sfc.wide.ad.jp/~julien/papers/draft-charbon-nemo-multihoming-evaluation-00.txt] > > Thanks. > > -- Julien Charbon & > Chan-Wah Ng > > [1] http://www.ietf.org/html.charters/nemo-charter.html --Multipart_Tue__15_Jul_2003_23:50:49_+0900_083475a8 Content-Type: text/plain; name="nemo-agenda-ietf57.txt" Content-Disposition: attachment; filename="nemo-agenda-ietf57.txt" Content-Transfer-Encoding: 7bit # NEMO WG Draft Agenda 57th IETF, July 2003, Wien, Austria Chairs: Thierry Ernst T.J. Kniveton # Must Read List for this meeting: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-01.txt http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-00.txt http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-00.txt http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-01.txt http://www.sfc.wide.ad.jp/~julien/papers/draft-charbon-nemo-multihoming-evaluation-00.txt (missed cut-off date) http://www.ietf.org/internet-drafts/draft-jung-nemo-threat-analysis-00.txt Other drafts advertised on the NEMO ML (not in today's agenda): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ draft-droms-nemo-dhcpv6-pd-00.txt draft-hkang-nemo-ro-tlmr-00.txt draft-jeong-nemo-ro-ndproxy-00.txt draft-leekj-nemo-ro-pd-00.txt draft-lach-nemo-experiments-overdrive-00.txt draft-ohta-multihomed-isps-00.txt draft-park-mobileip-wifi-handover-00.txt draft-thubert-nemo-ipv4-traversal-01.txt o Agenda Bashing .............................................5 mins Chairs o NEMO status and milestones .................................5 mins Chairs o NEMO Basic Support ........................................30 mins draft-ietf-nemo-basic-support-00.txt Report from the design team and left issues Ryuji Wakikawa o IPR Status.................................................10 mins TJ Kniveton o Multihoming ...............................................20 mins draft-ng-nemo-multihoming-issues-01.txt draft-charbon-nemo-multihoming-evaluation-00.txt - what scenarios must be supported in Basic - issues with NEMO Basic Support - how are we going to proceed o Threat Analysis Discussion ............................... 15 mins draft-jung-nemo-threat-analysis-00.txt - what are the potential threats - how are we going to proceed o Terminology and Requirements Updates.......................15 mins draft-ietf-nemo-requirements-01.txt draft-ietf-nemo-terminology-00.txt Thierry Ernst o Conclusion and next steps.................................. 5 mins --Multipart_Tue__15_Jul_2003_23:50:49_+0900_083475a8-- From owner-multi6@ops.ietf.org Tue Jul 15 11:09:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23466 for ; Tue, 15 Jul 2003 11:09:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRQ7-000LTw-2f for multi6-data@psg.com; Tue, 15 Jul 2003 15:08:47 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19cRQ4-000LTQ-LA for multi6@ops.ietf.org; Tue, 15 Jul 2003 15:08:44 +0000 From: Masataka Ohta Message-Id: <200307151456.XAA01819@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id XAA01819; Tue, 15 Jul 2003 23:56:13 +0900 Subject: Re: yesterday In-Reply-To: <20030715084436.GP18608@login.ecs.soton.ac.uk> from Tim Chown at "Jul 15, 2003 09:44:36 am" To: Tim Chown Date: Tue, 15 Jul 2003 23:56:13 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Tim; > I think an important message we saw from the multi6 session was that we can > do a great deal now for small/medium networks, including the interesting > SOHO case, with Christian's approach. As we discussed, Christian's approach works for a single link network, but not beyond. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jul 15 11:10:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23492 for ; Tue, 15 Jul 2003 11:10:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRQA-000LUL-PS for multi6-data@psg.com; Tue, 15 Jul 2003 15:08:50 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19cRQ7-000LTQ-76 for multi6@ops.ietf.org; Tue, 15 Jul 2003 15:08:47 +0000 From: Masataka Ohta Message-Id: <200307151453.XAA01811@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id XAA01811; Tue, 15 Jul 2003 23:52:57 +0859 Subject: Re: yesterday In-Reply-To: from Iljitsch van Beijnum at "Jul 15, 2003 10:18:33 am" To: Iljitsch van Beijnum Date: Tue, 15 Jul 2003 23:52:57 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > I once again want to object to the idea of putting a full routing table > in each host, as suggested by Masataka Ohta. I see a lot of practical > problems with this, I'm afraid you completely misunderstand the routng architecture. > I'm almost certain we need to create more or less a > completely new protocol for this to work as the only protocol that has > the right information is BGP but BGP needs manual configuration and > that is NOT something you want to do for each host. Then there is the Hugh? Read the draft. It says: Note that end to end multihoming works with the separation between inter domain BGP and intra domain routing protocols, if BGP routers, based on local policy of the domain, assign external routes preference values (metric) of intra domain routing protocols. > unnecessary resource consumption (IPv4 table using Zebra costs at least > 60 MB, a third of which is kernel memory wich can't be swapped out). Are you saying v6 routing table should bloat like that of v4 that multi6 should disband? > But the more fundamental problem is that all the really good stuff is > aggregated away in the global routing table, The goal of multi6 goal is to aggregate the global routing table. A good news is that there is no good stuff to be lost. > so the info you can derive > from that is by far inferior to what you can get from talking to the > other side. I don't mean _asking_ the other side, I mean doing > measurements on the packets going back and forth, the same way TCP does > to arrive at good round trip times. As I said yesterday TCP is not IP. The Internet is connectionless. Moreover, even TCP needs initial guess which address to use. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jul 15 11:14:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23669 for ; Tue, 15 Jul 2003 11:14:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRVh-000M5P-RH for multi6-data@psg.com; Tue, 15 Jul 2003 15:14:33 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.14) id 19cRVf-000M4M-1x for multi6@ops.ietf.org; Tue, 15 Jul 2003 15:14:31 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA26625 for ; Tue, 15 Jul 2003 16:14:29 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id QAA21830 for ; Tue, 15 Jul 2003 16:14:29 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6FFETD27161 for multi6@ops.ietf.org; Tue, 15 Jul 2003 16:14:29 +0100 Date: Tue, 15 Jul 2003 16:14:29 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: yesterday Message-ID: <20030715151429.GJ26381@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <20030715084436.GP18608@login.ecs.soton.ac.uk> <200307151456.XAA01819@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307151456.XAA01819@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, Jul 15, 2003 at 11:56:13PM +0859, Masataka Ohta wrote: > > As we discussed, Christian's approach works for a single link network, > but not beyond. That's your opinion :) It would be good to get more experience "in the field" seeing how far we can go with the existing toolbox, and what compromises we make in doing so. In that respect Christian's initiative is good for probing many areas. Tim From owner-multi6@ops.ietf.org Tue Jul 15 11:29:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24284 for ; Tue, 15 Jul 2003 11:29:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRjZ-000NY4-7X for multi6-data@psg.com; Tue, 15 Jul 2003 15:28:53 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19cRjV-000NX6-2P for multi6@ops.ietf.org; Tue, 15 Jul 2003 15:28:49 +0000 From: Masataka Ohta Message-Id: <200307151515.AAA02057@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA02057; Wed, 16 Jul 2003 00:15:30 +0900 Subject: Re: yesterday In-Reply-To: <3F13C80A.6090903@info.ucl.ac.be> from Cedric de Launois at "Jul 15, 2003 11:23:22 am" To: Cedric de Launois Date: Wed, 16 Jul 2003 00:15:29 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Cedric; As I have been documenting that: One may still be allowed, though discouraged, to have local configuration with dumb end systems and an intelligent proxy. But, such configuration should be implemented with a protocol for purely local use without damaging the global protocol. having proxies for really dumb hosts is discouraged but not prohibitted. But, do it locally. > Agreed. I think that putting all the informations in the end-hosts would > imply an unacceptable > waste of resources. Moreover, to best take advantage from the BGP > routing system, we should > get access not to only one BGP table but to _all_ the BGP tables of the > providers. This is > clearly unacceptable to put in all the end hosts. That is clearly unacceptable, though it has nothing to do with my proposal. So? > Of course. NAROS is not limited to just looking at BGP. It can monitor > the exit links, check their > correct utilization, and change accordingly the way it proposes the best > addresses. That's a job already done by the routing system. We know very well that having a central server for routing job is a bad idea. Let the job done by routers. > in a short period. Without lifetimes, the NAROS load would be rapidly > unacceptable. That is one reason against proxies, but there are a lot more. > Of course this does not mean that this timeout is always the best one. > This is always a > trade-off between the server load and the traffic engineering quality. No. Proper timeout is determined by applications. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jul 15 11:39:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24616 for ; Tue, 15 Jul 2003 11:39:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRtE-000OeU-41 for multi6-data@psg.com; Tue, 15 Jul 2003 15:38:52 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19cRtA-000Odq-SY for multi6@ops.ietf.org; Tue, 15 Jul 2003 15:38:49 +0000 From: Masataka Ohta Message-Id: <200307151530.AAA02178@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA02178; Wed, 16 Jul 2003 00:30:09 +0900 Subject: Re: yesterday In-Reply-To: <20030715151429.GJ26381@login.ecs.soton.ac.uk> from Tim Chown at "Jul 15, 2003 04:14:29 pm" To: Tim Chown Date: Wed, 16 Jul 2003 00:30:08 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-11.9 required=5.0 tests=BAYES_10,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Tim; > > As we discussed, Christian's approach works for a single link network, > > but not beyond. > > That's your opinion :) Not mine. We know PMTUD does not always work and you can't stop hosts just sending 1280B packet to a path MTU of which is 1280. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jul 15 11:39:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24637 for ; Tue, 15 Jul 2003 11:39:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRtr-000Ohi-DZ for multi6-data@psg.com; Tue, 15 Jul 2003 15:39:31 +0000 Received: from [81.160.16.8] (helo=smtp.ietf57.telekom.at) by psg.com with esmtp (Exim 4.14) id 19cRtk-000Oed-N2 for multi6@ops.ietf.org; Tue, 15 Jul 2003 15:39:24 +0000 Received: from lolo (lolo.ietf57.telekom.at [81.160.202.89]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with SMTP id h6FFcTk03557; Tue, 15 Jul 2003 17:38:30 +0200 (MEST) From: "marcelo bagnulo" To: "Christian Huitema" , "Kurt Erik Lindqvist" , Subject: RE: IETF 57 Multu6 WG - Monday morning session - minutes Date: Tue, 15 Jul 2003 15:37:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Spam-Status: No, hits=-18.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would like to extend a bit the answer to Pekka N. (it is not that i will tell anything new to Pekka, but perhaps this will clarify to others) In order to preserve established communications more than 7 minutes using MIPv6 you need to change the CN. However, perhaps (and a very big perhaps) the changes proposed in draft-bagnulo-mobileip-unreachable-hoa-00 can be adopted in MIPv6 because other reasons that multi-homing, since the proposed change also protects mipv6 communications when the HA is no longer reachable (actually, this was Pekka N. idea) Regards, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Christian Huitema > Enviado el: martes, 15 de julio de 2003 10:40 > Para: Geoff Huston; Kurt Erik Lindqvist; multi6@ops.ietf.org > CC: proceedings@ietf.org > Asunto: RE: IETF 57 Multu6 WG - Monday morning session - minutes > > > Geoff, > > Thanks for the notes. You made a slight typo in the reporting of > my talk, when you wrote "We appear to > be able to design solutions that require changes to the IPv6 standards, do > no require address rewriting at exit points, but it could work". > What I said was, "We appear to > be able to design solutions that ^do not* require changes to the > IPv6 standards, do > not require address rewriting at exit points, and could work." > > There is also a small typo in a response to Pekka. You wrote: > > PN: You need to change the address in both ends. > CH: The time appears to be around 5 or 6 minutes. > > > The actual question was "you need to change code at both ends" > (as Marcello explained, you need to do something to some MIPv6 > timers to be more efficient). The response was, "You don't need > to change code if you are satisfied with the default timers, > which appears to be around 5 or 6 minutes." > > -- Christian Huitema > > > > > ________________________________ > > From: owner-multi6@ops.ietf.org on behalf of Geoff Huston > Sent: Mon 7/14/2003 10:02 AM > To: Kurt Erik Lindqvist; multi6@ops.ietf.org > Cc: proceedings@ietf.org > Subject: IETF 57 Multu6 WG - Monday morning session - minutes > > > > Multi 6 Monday 1300 - 1500 > > Agenda - overview of submitted drafts > > Agenda bashing: none > > > - - draft-nikander-hip-mm-00.txt, Pekka Nikkander, 5 min > > > For background: > draft-moskowitz-hip-arch-03.txt > draft-moskowitz-hip-07.txt > > Host Identity Protocol (HIP) has been around for some time. New > namespace protocol with a history of around 4 years. Today sockets are > bound to IP addresses, forcing the IP address into a dual role of endpoint > identifiers and forwarding identifiers. HIP introduces a new namespace > between the network and transport layers. The sockets are bound to host > identifiers that are dynamically bound to IP addresses. Hosts are > identified with public keys, not IP addresses, and apps see only the HIP > identifiers. The apps need not change is the assertion. Hosts can easily > have both IPv4 and IPv6 addresses, and the assertion is that end-host > multi-homing and mobility is trivial. HIP Proxies are described as a kind > of a hack. HIP may be a part of the multi-homing architecture. 4 > Interoperating implementations, intend to send the drafts to the IESG, and > more work is needed on mobility and multi-homings with NAT traversal. HIP > is not a working group but is progressing in the background. HIP is a > multi-address solution with end-to-end. It solves only one aspect of > multi6, and has no specific solns for address selection or TE > > Matsataka Ohta: You said "HIP Proxy" - do you support > multi-proxies for backup > Pekka Nikkander: There is no easy way to have multi HIP proxies in some > situations, and it does represent a single point of failure > > > > - - draft-coene-sctp-multihome-04.txt, Lode Coene, 15 min > > > SCTP approach - endpoints have multiple addresses, where each > IP address > represents a path to a particular endpoint. SCTP is not aware of the level > of path distinguishing - it would be good if they were, but this is not a > known property. SCTP can detect path up/down. (Example of > host-to-host with > 2 addrs on each host). Multi-homing open up new horizons for SCTP: add and > remove ip addresses dynamically to the endpoint, that can support > mobility. > Functionality at the endpoint is asserted to be superior to network > functions in this regards. It does imply that the host requires a routing > table - not a big deal for a host is the claim. But a big table > is required > for a system with a large connection load. How to maintain the routing > table is claimed to be implementation dependant (pre-configured or caching > the INIT). NATs are in the draft because they wanted to warn everyone how > bad NATs really are! NAT cases for SCTP generates problems that do no > appear to have straightforward solutions. From the transport level SCTP is > claimed to be a 'should work' solution. > > Lixia Zhang: How about UDP? > Lode Coene: its the same problem, with the application having to undertake > the selection. > Erik Nordmark: what algorithms have been used in SCTP work to > select source > and destinations? Any write ups of this work? > Lode Coene: none known to me. > > > > - - draft-bagnulo-multi6-mnm-00.txt, Marcelo Bagnulo, 10 min > > Proposes to use MIPv6 to the multi-homing (mh) problem. Example in > presentation of recovery from current to backup path (Using alternate > addresses) Both paths have to be bound and identified _before_ an outage > using binding update messages. The alternate binding will use the Home > Address Option. Since MIP already needs the exchange of messages > along each > path, this exchange can be used as a path keepalive. The lifetime of the > binding is limited to 7 minutes, and this is considered to be very short. > Possible solutions are proposed > > Matsataka Ohta: IPv6 has large timeouts for various purposes. If your > proposal to have the same property so that the new address can be > used quickly. > Marcelo Bagnulo: this issue is to build a path outage detection, > and we are > proposed to use the packet exchange for this purpose. The idea is to use > the same packet format, but change the timing. > > > - - draft-ohta-e2e-multihoming-05.txt, Masataka Ohta, 20 min > > General introduction on IP and IPv6. References 8+8 Locator > and endpoint > I-D. The proposal is to let end systems have multiple addresses. Let the > other end select the 'best' address. (The host addresses are part of > multiple upstream aggregates). The general architecture proposed is to let > the network inform the host about state to allow the hosts to undertake > address selection. When should a host attempt alternate > addresses? Proposed > in response to ICMP, routing change, timeouts (TCP only). Proposed that > applications have an IP (and UDP)-defined packet timeout to trigger > alternate address use. For very short timeouts it is proposed to send > multi-copies of the packet with multiple addresses. e-2-e mh and IP > mobility are similar, although there is mobility timing at the IP layer. > e2emh has been implemented and running on NetBSD with LIN6, with > modifications to the stack as described in the presentation. The design > framework proposed is to make everything optional. Exercising no > options is > single-homed. Use 8+8 Locator/Id separation, with packet reception and > connection identification determined by the ID. Application to mobility is > also described. Multiple addresses are supplied to the peer by reverse > query of DNS using an ID query key followed by a forward query, > or carry in > the TCP header or a new DNS query type. e2e approach is proposed as > scaleable architecture. MH and mobility are related, and the approach uses > 8+8 separation > > Pekka Nikkander: You did not mention security issues in your > presentation - > is this to be addressed later on, or do you have comments now? > Matasaka Ohta: The current Internet is weakly secure. > Cookie-based security > for locator change give only the same level of security. > > Peter Werny: What is required in the DNS for this to work? > Matasaka Ohta: this is different from current V6, as it only uses the > identifier 8 bytes. In DNS we look up locators of location agents using ID > of hosts. > Peter Werny: Every host has to have a DNS entry? > Matasaka Ohta:If there is no DNS and not TCP then you are > single-homed, and > you cannot use this mechanisms. > PW: Your draft has no mention of DNS update > Matasaka Ohta: Location is not in the DNS - just the location agent. > Erik Nordmark: Are you assuming a structure for the identifiers? > Matasaka Ohta: It should be reverse lookup-able. Its better to have > hierarchy in the identifier space, but you can do without hierarchy if you > use TCP instead of the DNS to pass the multiple addresses > > > > - - draft-ohira-assign-select-e2e-multihome-00.txt, FUJIKAWA Kenji, 5 min > > Each end application can determine a route to use. > Applications select a > route using a selection of a specific source and destination address pair. > An end application can select a path without full route information is the > claim. The attributes are claimed to include redundancy and load > balancing. > Modifications to hosts, routers and routing protocols is needed. Site exit > router selection using source address routing enables redundancy, load > sharing with multiple paths. Some mechanisms is needed for 'proper' source > address selection. Transport layer survivability could be an SCTP > mechanism > or other. > > > > - - draft-arifumi-lin6-multihome-api-00.txt, Arifumi Matumoto, 10 min > > Socket API extensions. Propose to use application layer, > rather than the > network. Uses 8+8 model. The API is for manipulation of multiple addresses > in the application. LIN6 is based on the 8+8 model. LIN6 does address > acquisition, notification, registration in a secure manner. Hosts identify > their peer and themselves using only the identifier part. e2e-mh > is seen to > be an application of the LIN6 model. The trigger to switch > locators is seen > to be ICMP-based using host unreachable. APIs need to manipulate locators, > to make a multi-locator-ready socket, allow API to change locators on the > fly, and acquire remote locators. The details of API changes described, in > socket(), getaddrinfo() and getsockopt()/setsocketopt(). APIs are intended > for active mh applications. UDP requires application support. Future work > is to put support in to the TCP level, so that no changes are required for > API for TCP. > > > - - draft-ohta-multihomed-isps-00.txt, Masataka Ohta, 10 min > > All hosts should have full default-free routing table. This allows > selector in host to make optimal locator choice, and know when locator is > unreachable. source address selection for ingress filtering only. The peer > will not use the source address - it will make its own selection of a > locator for the peer. Extended example of policy control and filtering. > > > Pekka Savola: Both of these drafts have been obsoleted > Matasaka Ohta: not a problem! > ? (MCI): IF an NLA gets address space from 2 TLAs which does it use? > MO: If gets 2 addresses, as does its customers. The number of prefixes > cascades down. > ? MCI): Scaleaility? > MO: yes, and NLA should be no more than triply homed. > Iljitsch van Beijnum: Why is the information in the routing table superior > to information you can obtain from the other end? > MO: This does not have scaleability problems if you limit connectivity. > This is a connectionless system where a host has no information about the > other end, and the routing table is local information you can use. > Iljitsch van Beijnum: ok, but I disagree with this > > > > - - draft-de-launois-multi6-naros-01.txt, Cedric de Launois, 10 min > > > Solution for traffic engineering for mh need sites in a multi-address > environment. Each host has 1 address per upstream provider. Noted that > choosing a source address implies choosing a provider (assuming providers > perform source address filtering). Which source? A host has no information > about which provider to use to reach a destination. Propose to use a > dedicated agent (server). A host will query the server with a destination > address, and the server responds with the source to use. The burden of > selecting the source address is aggregated to a dedicated server. Note it > gives only a hint to the host about what address to use. NAROS is not > intended to preserve flows across address changes. SCTP or HIP could be > used to preserve flows. The server could be anycast, or undertaken without > provider interaction. The host / server protocol is a query > response packet > exchange. Where multiple choices exist, multiple parameters can be used to > make the selection. > > Pekka Nikkander: is this a new protocol, or, perhaps, ICMP > Cedric de Launois: No particular protocol - it could be ICMP > PN: There are security issues here, like secure neighbor discovery > Michael Richardson: Takes the example and adds further connections, and > then adds a policy question about 'acceptable traffic' policies. Can NAROS > deal with this> > CdL: A lot of requirements could be placed in the NAROS server > and it could > be aware of those kind of requirements. > Matsataka Ohta: Anycast does not include increased robustness for server > failure. A NAROS server crash will not bring down a anycast > route. Also 300 > seconds is too large a value. > > > > - - draft-huitema-multi6-hosts-02.txt, Chistian Huitema & David > Kessens, 20 min > > Simple multihoming experiment. A problem statement in a bounded example > environment. A simple network is a single link where multiple hosts see > multiple boundary routers where each router is connected to distinct > upstreams. Addresses from providers are mapped to all the hosts. Asserted > that this is not uncommon in V4 and that the common solution is to NAT the > local net and allow the NAT to 'rehome' to each outbound. The consequence > is flow breakage across the rehoming of the NAT. The bounds are that the > ISPS do not exchange information, there are provider addresses with an > assigned prefix per provider. Hosts configure an address with each prefix. > Need to resolve host choice of egress router selection (as a function of > the source address) > > Erik Nordmark: There are people talking about movement > detection, and this > gets all routers to advertise all prefixes > Christian Huitema: Thats not incompatible - several routers can advertise > the same information, provided that the information is equivalent, and the > routers can handle all such packets. > Pekka Savola: please clarify the applicability. This is only the > case where > hosts are directly connected to all egress routers. > Christian: this is a common case. > MO: You don't need tunnels in a single link network. In a multi-link > network you need tunnels. > CH: This does nothing for MTU discovery. For single link there is a very > simple solution and this can be extended for multi-links > MO: Ands I'm saying its impossible > CH: fine! > > No need for tunnels in a single link network, and the routers can pass > off to each other in the event of dynamic failure. The assertion > is that in > a single link network this requirement can be easily met. Dead exist > routers or dead ISP require some consideration. If the exit router knows > that the path is dead it can send a poison advertisement of the > prefix. The > real issue with this form of mh is a very soft definition of > 'broken' where > the link may be up, but the path to the remote end point may be unuseable. > This kind of problem is an e2e detection issue. Hosts may need to keep > track of connections and track quality. If you know an ingress > path is dead > do you need to update the DNS to remove the dead prefix from your host > entry? Of course you may not know and in this case your peer will need to > work out what address to use. Maintenance of TCP connections is an issue. > MIP6 may be an answer, or SCTP for 'new hosts'. For 'old' hosts, he > connection will fail, and needs to be reestablished. Exit / entrance > selection is also an issue. One approach is to only advertise the > preferred > address in the DNS if you have a primary / backup scenario. And in a 1 + 1 > scenario, then advertise both. On the outgoing the solution may be a local > server to assist, or to document preferences in the routers. We appear to > be able to design solutions that require changes to the IPv6 standards, do > no require address rewriting at exit points, but it could work, > > Pekka Nikkander: New hosts can use MIPv6 or SCTP. IN MIPv6 don't you need > to change both ends? > CH: The support for the connected node in MIPv6 is supposed to be > implemented everywhere. > PN: You need to change the address in both ends. > CH: The time appears to be around 5 or 6 minutes. > PN: If you are going to change the code at both ends then you should try > HIP in your experiments as well. > CH: You are free to experiment with HIP > Fujikawa: It seems like an application cannot select different path from > other applications in a host? > CH: No, not so. The host has several IPv6 addresses. An application that > want to do path selection can bind to a source address and connect to a > destination and select a path. > Matasaka Ohta: It is stupid to keep using a complication MIPv6 > CH: Complexity is management of the Home agent and security functions to > certain classes of attacks and you will need to have some form > of security > in any case. > Matasaka Ohta: This only works in a single link case. > > In a larger site the problem is ingress filtering, because its > harder to > do source-based routing. The simple solution is to work with the ISP to > lift source filters. Even larger sites have their own PI space and AS#. > > IvB: Disable ingress filtering can be down for the local upstream, but the > chain may extend upward > CH: ingress filtering in the middle of the Internet is a bad idea > MO: what will you do with a large site? > CH: lets call them medium > Bob Hinden: ISPs would be more amenable to break ingress filtering than > route specifics. > ?: Ingress filtering should not be an issues. > Mat Ford: Define a large site? > CH: establish a registry relationship! > > > - - draft-savola-multi6-asn-pi-00.txt, Pekka Savola, 10 min > > > Claimed that this is not the best solution in all cases, but > better than > some others. Need to avoid the routing mess of advertising more specific > and need solutions soon. Approach to use the AS number to create PI space > for larger enterprises. e.g. 2000:::/32. Issues about 16 / 32 bit AS > numbers, and a claim that 32 bit AS numbers would indicate a RIR policy > failure. > > > > Moshens VC(?): How do you get uniqueness of the prefix > PS: This is 2000 - it won't collide! > MO: There are already too many ASes deployed > Geoff Huston: You are assuming AS remain at 16bits. What happens when AS > drain in 2011. and we move to 32 bit AS numbers? This is a > relatively short > term solution with a visible drop dead point - right? > PV: yes. > ?: This is good solution > PV: an appendix shows how to deal with 32 bit AS numbers, but I > don't lkike > this solution. > Tim Chen: This cuts out the smaller sites that do not have ASs. > Randy Bush: Why reluctant to give out ASes to routing domains who's policy > domains are different from their neighbors? > > > - - draft-van-beijnum-multi6-isp-int-aggr-01.txt, Iljitsch van Beijnum, > 15 min > > > Geographical aggregation. Admitted that topology is not correlated to > geography, and even if the geo part doesn't work there are still > some savings. > > MH: This gives little actual aggregation > ?: Asymmetrical routes break in your model > IvB: Routing is asymmetrical in multi-homing in any case. > Tony Hain: Aggregatibility is the question. The concept appears fine, but > you are making assumptions about aggregation boundaries here. > > > > > > > From owner-multi6@ops.ietf.org Tue Jul 15 11:50:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24968 for ; Tue, 15 Jul 2003 11:50:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cS4C-000PvE-Cw for multi6-data@psg.com; Tue, 15 Jul 2003 15:50:12 +0000 Received: from [81.160.16.8] (helo=smtp.ietf57.telekom.at) by psg.com with esmtp (Exim 4.14) id 19cS48-000Pmv-NS for multi6@ops.ietf.org; Tue, 15 Jul 2003 15:50:08 +0000 Received: from lolo (lolo.ietf57.telekom.at [81.160.202.89]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with SMTP id h6FFnVk03590; Tue, 15 Jul 2003 17:49:31 +0200 (MEST) From: "marcelo bagnulo" To: "Iljitsch van Beijnum" , Subject: RE: Multihoming experiment Date: Tue, 15 Jul 2003 15:48:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Spam-Status: No, hits=-18.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Iljitsch, > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Iljitsch van Beijnum > Enviado el: martes, 15 de julio de 2003 14:20 > Para: multi6@ops.ietf.org > Asunto: Multihoming experiment > > > A few observations on Christian and David's multihoming experiment: > > This means source address dependent routing, I would say that source address based routing is one of the options, as mentioned in Christian?s draft. I guess that the point here is which element has the knowledge to decide which exit path to use. One option is to maintain current paradigm, where the routing system within the site decides which exit will be used by the packet. In this case, we need that the routing system informs the host which source address the host has to include in the packet, so that it is compatible with the ingress filtering that is configure in the exit path that has been selected by the routing system. There is simple solution for this that is included in Christian?s draft and it has also been mentioned several times by F. Dupont and which is to define a new ICMP source address redirection message. So the hosts select a source address and the routing system carries the packet to an exit router. If the source address is compatible, then ok the packet is forwarded. If the source address is incompatible with the exit selected, then the router issues the ICMP message indicating that an alternative source address has to be used. The other option is to asssume that the exit path is defined by the host, this would be the case where policies are defined within the host (for instance configuring the policy table defined in rfc 3484 or the other option is consulting the NAROS server) In any case, the exit router selection is no longer performed by the routing system looking at the destination addres, but it has been already performed by another system, (host, NAROS) when the source address was selected. At this point, the routing system inside the site becomes very simple: it only has to look the source address prefix and forward the packet to the correct exit.I think this can actually be an interesting feature, i mean, routing table of the router inside the site will only have as many entries as exit paths. I agree that there are no routing protocols currently defined for handling this kind of source address based routing, but perhaps this should not be so difficult, considering that the complexity has been moved somewhere else (to the element that selects the source address) We have been discussing these issues with Cedric and we are considering to work on some of these issues to see how it would work and see possible limitations. Comments? Regards, marcelo & Cedric but I don't think this > term is used anywhere. The consequence of this is that sites that > implement this CANNOT use any form of dynamic routing. Also, I'm afraid > there will be traffic engineering problems because of RFC 3484 for > hosts that implement this. For instance, if at some point the RIRs use > up 2001::/16 and they start giving out address space from 2003::/16, a > host with a 2001:: and a 2003:: address will use the router that > announces the 2001:: prefix for all traffic to 2001::/16 which would be > nearly all of the IPv6 internet. > > And note well, from RFC 3484: > > Well-behaved applications SHOULD iterate through the list of > addresses returned from getaddrinfo() until they find a working > address. > > Applications that don't implement this will have to wait for a prefix > to become deprecated to switch to the other one, so the multihoming > benefits for those applications would be even smaller. > > From owner-multi6@ops.ietf.org Wed Jul 16 03:33:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18635 for ; Wed, 16 Jul 2003 03:33:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cglj-0000eg-4L for multi6-data@psg.com; Wed, 16 Jul 2003 07:32:07 +0000 Received: from [3ffe:501:100c:d120::53] (helo=shonan.sfc.wide.ad.jp) by psg.com with esmtp (Exim 4.14) id 19cgld-0000c6-Ib for multi6@ops.ietf.org; Wed, 16 Jul 2003 07:32:01 +0000 Received: from localhost.nautilus6.org (unknown [81.160.206.92]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 97A825D0AA; Wed, 16 Jul 2003 16:31:18 +0900 (JST) Date: Wed, 16 Jul 2003 16:28:17 +0900 From: Thierry Ernst To: multi6@ops.ietf.org Cc: Tim Chown Subject: Re: FYI draft-charbon-nemo-multihoming-evaluation-00.txt Message-Id: <20030716162817.3928f4cb.ernst@sfc.wide.ad.jp> In-Reply-To: <20030715150439.GF26381@login.ecs.soton.ac.uk> References: <20030714212236.04f372ab.julien@sfc.wide.ad.jp> <20030715235049.64065525.ernst@sfc.wide.ad.jp> <20030715150439.GF26381@login.ecs.soton.ac.uk> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-26.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_LONG_DENSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > > Just to add based on this, we will have a slot discussing about > > multihoming in the NEMO session tomorrow at 18.00 pm. Your participation > > would be appreciated. > > Sorry, I meant 1PM... During the NEMO meeting, we want to decide what multihoming scenarios are relevant in our WG (based on the 8 scenario in the taxonomy draft), and how the WG is going to handle it. Also, what are the issues with NEMO Basic Support. > > I have attached the agenda. Comment on the 2 multihoming drafts and > > comments on section "multihoming" in draft-ietf-nemo-terminology-00.txt > > would be appreciated. > > # NEMO WG Draft Agenda > > 57th IETF, July 2003, Wien, Austria > > Chairs: Thierry Ernst T.J. Kniveton > > > > # Must Read List for this meeting: > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-01.txt > > http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-00.txt > > http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-00.txt > > http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-01.txt > > http://www.sfc.wide.ad.jp/~julien/papers/draft-charbon-nemo-multihoming-evaluation-00.txt > > (missed cut-off date) > > http://www.ietf.org/internet-drafts/draft-jung-nemo-threat-analysis-00.txt > > > > > > Other drafts advertised on the NEMO ML (not in today's agenda): > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > draft-droms-nemo-dhcpv6-pd-00.txt > > draft-hkang-nemo-ro-tlmr-00.txt > > draft-jeong-nemo-ro-ndproxy-00.txt > > draft-leekj-nemo-ro-pd-00.txt > > draft-lach-nemo-experiments-overdrive-00.txt > > draft-ohta-multihomed-isps-00.txt > > draft-park-mobileip-wifi-handover-00.txt > > draft-thubert-nemo-ipv4-traversal-01.txt > > > > > > o Agenda Bashing .............................................5 mins > > Chairs > > > > o NEMO status and milestones .................................5 mins > > Chairs > > > > o NEMO Basic Support ........................................30 mins > > draft-ietf-nemo-basic-support-00.txt > > Report from the design team and left issues > > Ryuji Wakikawa > > > > o IPR Status.................................................10 mins > > TJ Kniveton > > > > o Multihoming ...............................................20 mins > > draft-ng-nemo-multihoming-issues-01.txt > > draft-charbon-nemo-multihoming-evaluation-00.txt > > - what scenarios must be supported in Basic > > - issues with NEMO Basic Support > > - how are we going to proceed > > > > o Threat Analysis Discussion ............................... 15 mins > > draft-jung-nemo-threat-analysis-00.txt > > - what are the potential threats > > - how are we going to proceed > > > > o Terminology and Requirements Updates.......................15 mins > > draft-ietf-nemo-requirements-01.txt > > draft-ietf-nemo-terminology-00.txt > > Thierry Ernst > > > > o Conclusion and next steps.................................. 5 mins > > > > -- Thierry Ernst, WIDE at Keio University, Japan E-mail: ernst@sfc.wide.ad.jp Web: http://www.sfc.wide.ad.jp/~ernst/ -- Jun Murai Lab Shin-Kawasaki Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki Kanagawa, 212-0054 Japan Phone : +81-44-580-1600 Fax : +81-44-580-1437 Mobile: 090-9815-8023 From owner-multi6@ops.ietf.org Wed Jul 16 04:58:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21829 for ; Wed, 16 Jul 2003 04:58:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ci6A-00061r-BM for multi6-data@psg.com; Wed, 16 Jul 2003 08:57:18 +0000 Received: from [130.54.22.68] (helo=century.kuis.kyoto-u.ac.jp) by psg.com with esmtp (Exim 4.14) id 19ci62-00061C-22 for multi6@ops.ietf.org; Wed, 16 Jul 2003 08:57:10 +0000 Received: (qmail 62453 invoked by uid 0); 16 Jul 2003 17:56:48 +0900 Received: from century.kuis.kyoto-u.ac.jp (HELO miako-232-253.kyoto-inet.or.jp) (130.54.22.68) by century.kuis.kyoto-u.ac.jp with SMTP; 16 Jul 2003 17:56:48 +0900 Date: Wed, 16 Jul 2003 17:56:31 +0900 Message-ID: <3w3ch6etog.wl@miako-232-253.kyoto-inet.or.jp> From: FUJIKAWA Kenji To: Geoff Huston Cc: Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: Re: IETF 57 Multu6 WG - Monday morning session - minutes In-Reply-To: <5.1.0.14.2.20030715025859.01bd45f8@localhost> References: <5.1.0.14.2.20030715025859.01bd45f8@localhost> User-Agent: Wanderlust/2.6.1 (Upside Down) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-21.6 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > > - - draft-ohira-assign-select-e2e-multihome-00.txt, FUJIKAWA Kenji, 5 min > OHIRA Kenji, who is the first auther, made a presentation instead of me. > Each end application can determine a route to use. Applications select a > route using a selection of a specific source and destination address pair. > An end application can select a path without full route information is the > claim. The attributes are claimed to include redundancy and load balancing. > Modifications to hosts, routers and routing protocols is needed. Site exit > router selection using source address routing enables redundancy, load > sharing with multiple paths. Some mechanisms is needed for 'proper' source > address selection. Transport layer survivability could be an SCTP mechanism > or other. --------------------------------------------------------------- FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan WWW: http://www.lab1.kuis.kyoto-u.ac.jp/~fujikawa/index-e.html TEL +81 75-753-5387 FAX +81 75-751-0482 E-mail fujikawa@real-internet.org From owner-multi6@ops.ietf.org Wed Jul 16 09:00:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28503 for ; Wed, 16 Jul 2003 09:00:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19clrx-000Kw4-SQ for multi6-data@psg.com; Wed, 16 Jul 2003 12:58:53 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19clrt-000Kvf-OE for multi6@ops.ietf.org; Wed, 16 Jul 2003 12:58:50 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6GCxUxS045468 for ; Wed, 16 Jul 2003 14:59:30 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 16 Jul 2003 14:58:45 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: More random and not so random thoughts From: Iljitsch van Beijnum To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <3BB28B4C-B78D-11D7-9CB7-00039388672E@muada.com> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_30,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit First some things I want to clarify after this morning. Note that I am not speaking on behalf of the design team here. I suppose it would be a good idea to get a working definition of "multiaddressing". I think the idea is that a host gets more than one address. At some point this host will start emitting packets to the network. The most basic problem that we must solve in order for this to work is the source address selection problem. Something better than RFC 3484 for the destination address would be very useful too. I think we can address this separately from whatever else we're going to do. So by all means, work such as NAROS should continue. Now if hosts have more than one address (which already happens regularly in IPv4 and should be considered almost the norm in IPv6) then one of three things can happen: 1. The application doesn't know about multiple addresses, so default address selection kicks in. This doesn't reliably work today in the presence of ISP ingress filtering. This unhappiness needs to be resolved one way or the other, so see above. (Single homing because multihoming is worse isn't good.) 2. The application cycles through (a reasonable subset of) all addresses. This should work reasonably well, but it sessions can still break because of a routine routing change. So still see above. Also, I'm sure there are applications for which implementing all of this is appropriate, but I don't think it's reasonable to require handling all of this from application writers. And there are many reasons, both very pragmatic and much more fundamental, why I think this is simply the wrong approach for the general case. 3. Some intermediate layer handles this. This could be a special transport (SCTP), mobility or of course the latest and greatest loc/id stuff. To me, all of this could be "multiaddressing" but I'll try to avoid that word from now on. If someone can come up with some new non-confusing terminology for all of this I promise I'll try to use it. So here is my reasoning on where the handling of multiple addresses should happen: Applications: not a good idea: - there are many applications, doing the same work many times - application writers usually don't understand network stuff so they are likely to get some of it wrong - applications can have a surprisingly long shelf life while OSes _usually_ get updated at some point, and supporting legacy apps is hard enough as it is - limited to things that can be done on one end most of the time Each OS for itself: not a great idea - makes porting applications harder - little useful tradition in interoperation here - again duplication of effort and often limited to doing stuff on one end Transport: good and bad - making TCP address agile would have a very siginificant benefit: TCP already keeps track of important end-to-end information that can be reused to good effect. - doing a lot of stuff for each individual session is inefficient as many applications use very short-lived sessions - doing this for each transport protocol is infeasible as protocols like UDP don't have the necessary hooks to do this IP: not so bad and not so good - this can be a general mechanism, do it once, solve the problem forever - possibility of offloading processing to middlebox for policy, efficiency or speedy deployment Ideally, we could start by implementing this in middleboxes. Yes, middleboxes suck but doing multihoming in the face of restrictive RIR policies and strange filters in far away networks isn't much fun either. Then everything is implemented in the OSes. Now there is a tradition in Unix where TCP and IP are in practice completely comingled. So even though we define this mechanism to work at the IP layer, TCP implementations could easily incorporate this and start doing *really* interesting things such as load balancing a single session over multiple paths. And if we're careful when defining all of this, it should be possible to drop in a new namespace if and when this is considered desirable. Christian says implementing this would turn OSes upside down. But I simply don't see this. It seems to me that this could be entirely contained to the (TCP/)IP stack. Applications simply revert to IPv4 behavior where they connect to a single address and if it is possible to set up the session, it will happen, and if not, the connection fails. No need to do anything complex. Now obviously we can define one or more more advanced APIs that let smart applications look deeper inside the network. This would be more work than in the situation where we don't change anything, but I don't think smart applications really get to do what they need to do now anyway. About the roadmap/more desing teams thing: I'm afraid of a situation where a good core idea doesn't take some limitations in consideration so the resulting proposal is flawed. It looks like this is already the case with e2e/lin6, but I have to read a bit more about those before I can say anything conclusive here. Hopefully the chairs can figure out a way to avoid this from happening. Iljitsch From owner-multi6@ops.ietf.org Wed Jul 16 11:08:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05375 for ; Wed, 16 Jul 2003 11:08:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cnrp-00042v-Bh for multi6-data@psg.com; Wed, 16 Jul 2003 15:06:53 +0000 Received: from [81.160.16.8] (helo=smtp.ietf57.telekom.at) by psg.com with esmtp (Exim 4.14) id 19cnrk-000416-6j for multi6@ops.ietf.org; Wed, 16 Jul 2003 15:06:48 +0000 Received: from info.ucl.ac.be ([81.160.183.138]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6GF6Ek27233 for ; Wed, 16 Jul 2003 17:06:15 +0200 (MEST) Message-ID: <3F156970.6050404@info.ucl.ac.be> Date: Wed, 16 Jul 2003 17:04:16 +0200 From: Cedric de Launois User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Source address selection in IPv6 multihomed multi-addressed sites Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-9.4 required=5.0 tests=BAYES_20,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit These are my random thoughts about source address selection in IPv6 multihomed multi-addressed sites. I believe this problem needs to be resolved to get a complete IPv6 multi-addressing multihoming solution. We assume here that the providers perform ingress filtering. I'm here only looking to solutions where the source address selection is not made by applications, but it is done "automagically". However, for all these solutions, it is possible to imagine some mechanism where the applications can overload the automatic behaviour. Here is my understanding of the different solutions proposed. * A solution is to perform source address based routing inside the multihomed site. The packets are always routed to the site exit router corresponding to the source address used. Pros: - no new option/protocol - no modification to hosts - no tunnel - routing efficiency (dumb routing) ? Cons: - possibly very bad load-balancing if all the hosts choose the same source address (and this is what they'll do with RFC3484 !) + no way to engineer the traffic if no additionnal mechanism is used - source address based routing has probably much more implications than what it is expected. This needs to be studied further. My point of view : maybe source address based routing is not something desirable. Anyway, source address based routing alone is not sufficient. * Another solution is to establish tunnels between the site exit routers. When a packet with a wrong source address is received by a site exit router, it is tunneled to the right exit router. Pro : no modification to hosts Cons: - a tunnel, reducing the MTU - no way to engineer the traffic My POV: I think this solution is too rigid and that a solution based on an ICMP source redirect can lead to a better solution without adding much more cost. * A third solution is that a host first try a source address (at random?). If the source address is not correctly chosen (e.g. the link is down), then a new source ICMP redirect is sent by the site exit router to the host. This ICMP message tells the host which source address to use. Pro : no tunnel Cons: - modifications needed on the hosts - at first look, difficult to engineer the traffic with this mechanism My POV: I think this solution is the most credible when the site is small and doesn't need complex policies. However I think the ICMP source redirect message should also contain a prefix associated to the source, like in the NAROS response messages. This would allow the host to fill its policy table step by step. This approach has to be reserved for small sites with few requirements. * A fourth solution is that a service (NAROS) tells the hosts which source address to use. Pro : - the most complete solution since it allows any kind of traffic engineering - no tunnel Cons: - also the most complex solution since it requires changes in the hosts and to set up a new service - implies source address based routing My POV: isn't that too complex for small sites ? Maybe. Is there a need to manage complex requirements is host-centric multihomed sites ? Probably. Anyway, the solution has the advantage of being rather complete. At the price of complexity. * A fifth solution is that the hosts know which source address to use thanks to DHCP. When they boot, they receive a full policy table from their DHCP server. This policy table contains informations about which destination is accessible through which site exit router etc. Pros: - no tunnel - easy configuration Cons: - requires a new DHCP option. Modifications to host are needed - complex traffic engineering not supported - no dynamic, how to react to a failure ? - implies source address based routing My POV: seems to rigid for me. At almost the same price, we can get the same features + dynamic with the ICMP solution. * A sixth solution is that a host tries to detect by itself which source address to use. A proposition is that a host maintain by itself one or more full BGP tables so that it can deduce the source address to use. Pro : no tunnel Cons: - waste of computer resources (how much ?) - no easy configuration Any comment/suggestion/correction ? Cédric From owner-multi6@ops.ietf.org Thu Jul 17 03:30:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20038 for ; Thu, 17 Jul 2003 03:30:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19d3C1-000Ajz-2L for multi6-data@psg.com; Thu, 17 Jul 2003 07:28:45 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.14) id 19d3BR-000AiY-3t for multi6@ops.ietf.org; Thu, 17 Jul 2003 07:28:09 +0000 Received: from coe-5bx15vd3ltq (ratree.psu.ac.th [192.168.100.3]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h6H7R8825793; Thu, 17 Jul 2003 14:27:11 +0700 (ICT) Date: Thu, 17 Jul 2003 14:27:11 +0700 (SE Asia Standard Time) From: lek To: Cedric de Launois cc: multi6@ops.ietf.org Subject: Re: Source address selection in IPv6 multihomed multi-addressed sites In-Reply-To: <3F156970.6050404@info.ucl.ac.be> Message-ID: X-Warning: UNAuthenticated Sender MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Status: No, hits=-22.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: QUOTED-PRINTABLE Hello Cedric, I wonder in any solution impling source address based routing that is it possible to use routing header instead of using source address based routing. If it could, I think using routing header is easier than source address based routing. Please correct me if I misunderstood. Regards, Pornpitak. On Wed, 16 Jul 2003, Cedric de Launois wrote: > These are my random thoughts about source address > selection in IPv6 multihomed multi-addressed sites. > > I believe this problem needs to be resolved to get > a complete IPv6 multi-addressing multihoming solution. > We assume here that the providers perform ingress > filtering. > I'm here only looking to solutions where the source > address selection is not made by applications, but it > is done "automagically". However, for all these solutions, > it is possible to imagine some mechanism where the > applications can overload the automatic behaviour. > > Here is my understanding of the different solutions > proposed. > > * A solution is to perform source address based routing > inside the multihomed site. The packets are always > routed to the site exit router corresponding to the > source address used. > > Pros: - no new option/protocol > - no modification to hosts > - no tunnel > - routing efficiency (dumb routing) ? > > Cons: - possibly very bad load-balancing if all the > hosts choose the same source address (and this > is what they'll do with RFC3484 !) + > no way to engineer the traffic if no additionnal > mechanism is used > - source address based routing has probably > much more implications than what it is > expected. This needs to be studied further. > > My point of view : maybe source address based routing > is not something desirable. Anyway, source address based > routing alone is not sufficient. > > * Another solution is to establish tunnels between the > site exit routers. When a packet with a wrong source > address is received by a site exit router, it is > tunneled to the right exit router. > > Pro : no modification to hosts > Cons: - a tunnel, reducing the MTU > - no way to engineer the traffic > > My POV: I think this solution is too rigid and > that a solution based on an ICMP source redirect can > lead to a better solution without adding much more > cost. > > * A third solution is that a host first try a source > address (at random?). If the source address is not > correctly chosen (e.g. the link is down), then a > new source ICMP redirect is sent by the site exit > router to the host. > This ICMP message tells the host which source address > to use. > > Pro : no tunnel > Cons: - modifications needed on the hosts > - at first look, difficult to engineer the > traffic with this mechanism > > My POV: I think this solution is the most credible > when the site is small and doesn't need complex > policies. However I think the ICMP source redirect > message should also contain a prefix associated to the > source, like in the NAROS response messages. This would > allow the host to fill its policy table step by step. > This approach has to be reserved for small sites with > few requirements. > > * A fourth solution is that a service (NAROS) tells the > hosts which source address to use. > > Pro : - the most complete solution since it allows any > kind of traffic engineering > - no tunnel > Cons: - also the most complex solution since it > requires changes in the hosts and to set up > a new service > - implies source address based routing > > My POV: isn't that too complex for small sites ? Maybe. > Is there a need to manage complex requirements is > host-centric multihomed sites ? Probably. Anyway, the > solution has the advantage of being rather complete. At > the price of complexity. > > * A fifth solution is that the hosts know which source > address to use thanks to DHCP. When they boot, they > receive a full policy table from their DHCP server. > This policy table contains informations about which > destination is accessible through which site exit router > etc. > > Pros: - no tunnel > - easy configuration > Cons: - requires a new DHCP option. Modifications to > host are needed > - complex traffic engineering not supported > - no dynamic, how to react to a failure ? > - implies source address based routing > > My POV: seems to rigid for me. At almost the same price, > we can get the same features + dynamic with the ICMP > solution. > > * A sixth solution is that a host tries to detect > by itself which source address to use. A proposition > is that a host maintain by itself one or more full BGP > tables so that it can deduce the source address to use. > > Pro : no tunnel > Cons: - waste of computer resources (how much ?) > - no easy configuration > > > Any comment/suggestion/correction ? > > C=E9dric > > > From owner-multi6@ops.ietf.org Thu Jul 17 03:42:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20772 for ; Thu, 17 Jul 2003 03:42:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19d3Nd-000BXN-1t for multi6-data@psg.com; Thu, 17 Jul 2003 07:40:45 +0000 Received: from [81.160.235.37] (helo=laptop2.ietf57.telekom.at) by psg.com with esmtp (Exim 4.14) id 19d3NN-000BVo-98 for multi6@ops.ietf.org; Thu, 17 Jul 2003 07:40:30 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.ietf57.telekom.at (8.12.9/8.10.2) with ESMTP id h6H7eLk1001502 for ; Thu, 17 Jul 2003 09:40:23 +0200 (CEST) Date: Thu, 17 Jul 2003 09:40:16 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=fixed Subject: Fwd: Minutes / Notes From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-12.4 required=5.0 tests=BAYES_30,NO_EXPERIENCE,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Please find attached Geoff minutes from yesterday. Please send comments to me _off list_ and I will add them. You have one week to comment. Best regards, - - kurtis - > Multi6 - Wednesday AM > > > Wednesday slot > ************** > > > > - - Administrivia, Chairs, 5 min > > Notes: Geoff Huston > Agenda change: Add Pekka's second presentation that was deferred from > Monday > > > ** Humming to keep the v4 multi-homing it in the charter. > ** Vince Fuller volunteered to review Joe Abley's Draft. > ** Christian Huitema to accept a role in a second design team using an > approach drawing on mobile-IP mechanisms with multi-addressing > > > Notes:.... > > - - draft-savola-multi6-nowwhat-00.txt, Pekka Savola, 15 min > > The assumptions in this draft is that one size does not fit all > unless > its very long term, and different sites have different requirements > and > priorities. The draft advocates a piecemeal approach to the problem. > Break down the problem into a set of generic 'sites' and for each > look > at their motivations, timeframes and timeframe. Then look at shorter > measures that may be applicable. The classification is 'minimal, > 'small', 'large' and 'international and the slides / draft has the > details of the classification > > Matasaka Ohta: Do you mean that a site may be geographically separated? > Pekka Savola: yes > Matsakata Ohta: So full internal connectivity is a requirement for a > 'site'? > Pekka Savola: yes > Erik Nordmark: Its been very fuzzy as to what is a site and its in the > charter. Its ranged from campus to organization with internal > connectivity, and we don't need to decide what it is here again. > > The motivations listed include ISP independence, redundancy, load > sharing, and the various aspects of these three areas. Looking at the > solutions and how they map to this classification it appears that > multi- > connecting (same ISP) has some relevance to some shorter timeframes > in > some instances. The presentation listed some mechanisms against > timeframes (see presentation). > > Matsakata Ohta: How long is "short" etc in terms of time > Pekka Savola: no firm definition, but 'short' means around a year > Matsakata Ohta: I think that is very long. > > Conclusions in the draft were that multi-connecting is good and > should > be used more for bigger enterprises. Id/Locator separation in hosts > will > prevail, but it is not a universal solution to the entire problem. > Minimal sites may not have a high demand for multi-homing. Smaller > sites > may use multi-connecting, and larger cases may use host-centric with > multiple PA space. At the larger size PI space with AS is a more > likely > solution. The presentation has a large list of work to be done (see > presentation). Advocate working on short term solutions with host- > centric/site-exit when ISPS use Ingress Filtering and how to work > within > a 1500 octet bounded MTU to the external provider. Pekka advocates > also > working on documenting how to do renumbering or how to, at the least, > make renumbering easier. His list of open issues are one size fits > all > or piecemeal solutions, specific architectured solutions vs available > tools, and how to deal with 'difficult' requirements. > > Matsakata Ohta: What is meant by 'available' > Pekka Savola: something that has not been made up specifically. If its > implemented its available. > > > > > > - - Presentation from the design team, Iljitsch van Beijnum, 20 min > > Design team members: Tony Li, Erik, Pekka, Mike O'Dell, Sean Doran, > Dave > Katz, Brian Carpenter, Iljitsch van Beijnum. > > Look at the general overview rather than specific details. Their > definition of multihoming is connection to same ISP more than once, > or > more than 1 ISP. Expectations of redundancy/failover without > reconfiguration or manual intervention, load sharing across available > external connections and some concept of 'provider independence", by > being easily 'moveable' from ISP to ISP. The IPv4 approach was to > use PI > space and announce it in BGP through upstreams. This had an observed > routing table pressure. Current assignment policies limit this to > larger > sites with the minimum allocation size and minimum immediate take-up > levels. For others the approach is to use PA space and multi-announce > the PA fragment. This still requires renumbering on ISP mobility, > together with filtering issues and ISP policy associated with PA > space. > Multiaddressing is claimed to not really work in a multi-homed > context > in V4. NAT has been advocated in this context as well, and it may > make > some aspects easier, but it fails to gain real traction in V4. The > translation to IPv6. The claim is less than 25,000 multi-homed > 'sites' > in the V4 network today. The projection given in the presentation > looks > to 10M to 1G routing table as an eventual outcome, and its claimed > that > this is processing infeasible. Very large routing tables was claimed > to > have other hardware-related limits in terms of CAM sizes. For longer > term scalability the presentation advocated multiaddressing with > provider aggregateable address blocks and following provider > aggregation. Multiaddressing is not multihoming. The reachability > tuple > is (source addr, exit ISP, dest addr). The preference is to be able > to > set these independently, but with ingress filtering on source address > there is a need to match source addr to the selected exit ISP, and > the > exit ISP depends on the destination address. The Socket API expects > sessions with a 128 bit destination and source identifier field. > Breaking the API is not a path for multihoming. The V4 to V6 API > migration is advocated as a one-off exercise, rather than a precedent > for further API changes for multi-homing. The conclusion drawn is > that > applications at the API wants to see 1 address and the network needs > multiple addresses. This was called out as an opportunity for a > further > level of indirection (David Wheeler) > > Fijikawa: So you are saying that you don't want to change the API? > Iljitsch van Beijnum: Having to change the API for multihoming is a > very > big problem that may not be deployed for a long time > Fujikawa: So multihoming should be done without modifying the API? > Iljitsch van Beijnum: yes > Christian Huitema: I was interested in 2 points: multi-addressing does > not > work and the solution has to be based on multiaddressing. A draft of > the > points that break in multiaddressing today is a good idea. > Iljitsch van Beijnum: the focus is on TCP and you can't have a TCP that > switches addresses mid-flow because you don't have API support > Christian Huitema: The reason here is the protocol specification of > TCP, > not the API > Iljitsch van Beijnum: Obviously we can modify TCP without the API but > we > see modifying the network layer > Christian Huitema: The socket API constrains the solution you are > saying > that the socket API is the problem. A large number of applications > use a > higher level API. There are other APIS such as "connect by name" > Saying > we cannot move on the API is not necessarily true. > Iljitsch van Beijnum: that's a viewpoint of course but I'm resorting > the > design team > Kurtis Lindqvist: Is Christian's comment specific or generic? > Christian Huitema: It would be nice to have a list of things that are > not > working in multiaddressing, so if you have to go down this path you > know > what must be done. > Erik Nordmark: Maybe we are confusing things with terminology here. > > Multiaddressing is not a clearly defined term, and it is used in a > specific context in this presentation. Location / identifier > separation > observes that identifies are stable objects used by transport > protocols > and applications, Locators are dynamic objects used to forward > packets > through the network. The approach is to map a domain name to an > identifier and map the identifier to one or more locators. One > approach > is tunneling of an inner identifier with an outer locator packet > header. > More complex methods use 64 bit locators and 64 bit identifiers in > the > IPv6 address. This may ring some bells for some people as it similar > to > earlier proposals. The 'big' approach is 128 bit locators and > identifiers, and only one of these is in the 'outer' header at any > one > point in time, but they can be swapped. Tunneling is simple and > implementable, but have problems with the 40 byte per packet > expansion, > the co-location of tunnel endpoint to end host, and > ICMP/Firewall/PMTU > issues. The 'small' (64 bit) is that the host needs only know its > identifier, but there is an unstructured MAC address namespace that > cannot aggregate easily. Can't trust incoming locator/identifier > associations when you receive them. An attack path is to send an own > locator with a target identifier to divert traffic to the attacker. > There are changes to both hosts and routers to keep transport > protocols > working, and this can be slow. The 'big' (128 bit) has no per-packet > overhead, and can be implemented in either hosts or middle boxes. But > additional mechanisms and state are required for this mapping to be > maintained. All mechanisms use a distributed database to find current > locators for a given identifier. The source locator in incoming > packets > is used as a default destination locator, but the source is > ultimately > responsible for selecting a functional destination locator. This is > a IP > level association, not a per session association. ISP ingress > filtering > could be addressed with source locator rewrite, and the question is > whether this is wanted, and what information is lost. Other methods > may > be to use ICMP messages or NAROS approach. Consensus in the design > team > is the locator/identifier separation. There is agnostic response to > the > location within the site where multihoming happens. Don't trust > incoming > associations and the source is responsible for selecting the > destination > identifier. The practice approach us a name lookup to an identifier, > and pass this to transport. The transport sender maps source and > destination identifiers to locator. The receiver maps the locators > (source and dest) back to identifiers and pass to the application. > Open > issues are selection of which approach - no design team consensus. > Where > is the source of the locator and identifier space. Is this an overlap > with 'regular IPv6" none. Better path selection is necessary in > terms of > locator selection, and there are open issues with interdomain > multicast, > and in which order to so multihoming in IPSEC > > Matsakata Ohta: What is autoconfiguration? > Erik Nordmark: RFC2462 > > Fujikawa: Its not correct that 'small' needs host and router > modification. > Iljitsch van Beijnum: The way the design team saw it there were changes > required > Fujikawa: We believe this is possible without changes to routers. > Iljitsch van Beijnum: The drafts are yet to be written, so there is a > problem to describe this in detail > Sean Doran: Not made the assumption that the first part is necessarily > CIDR, and if we are not routing on this basis then changes are > required > Fujikawa: I don't understand at all > Alain Durand: Is there strucvture in these spaces or is it required to > be > flat? > Iljitsch van Beijnum: This was not considered in the design team > Alain: Is there reverse mapping required from locator to identifier to > name > Iljitsch van Beijnum: locators would be regular IP addresses and you > could > use the IP6.arpa space, but it did not come up in the design team > issues. > Matsakata Ohta: How large will the routing table be in V6? > Iljitsch van Beijnum: not discussed in the design team and there are > different ways to optimize this > Brian Carpenter: As a design team member, the answer is one of the > principle reasons for this separation is aggregatable locators, and > we > are hoping for a log(n) routing table because of this separation > Iljitsch van Beijnum: There are different ways to delegate here > Brian Carpenter: reverse lookup - locator to identifier lookup is > probably > going to be ambiguous and reverse is probably not going to be > possible > Erik Nordmark: The structure of identifier was not considered in the > design team. Personal thoughts are site or larger environments may > require some simple site / entity structure, but its yet to be > discussed > Lixia Zhang: Pointed to the comments about the untrustable nature of > locator/identifier associations on incoming packets, yet the design > team > is advocating this separated approach. Is this consistent? > Iljitsch van Beijnum: What is the problem here? > Erik Nordmark: Don't assume that there is a strongly bound association > between the two just by looking at received packets. > > > - - Open Mike, Chairs, 60 min > > > - - Future path for the mutli6 WG, Chairs, 20 min. > > > Kurtis Lindqvist: > > We've seen a number of presentations, including that of the design > team. > There are a few things to discuss first here, and there are WG > milestones that are lagging. > > There is a requirements document, but there are more on the charter. > > The other document remaining is version 4 multihoming to document > current multihoming practices Joe Abley has volunteered to complete > this > document, and Pekka's document may help. This document has expired. > > Question: should we complete this document or not? > > Iljitsch van Beijnum: forget about it - its too challenging > > Brian Carpenter: its a good document, but its not in V6 scope. Maybe > negotiate the charter to remove. Its a reasonable thing to take it > out > of the charter. There is benefit in documenting IPv6 multihoming. > > Sean: go to the list and ask for it to be dropped or complete it> > > Vince Fuller: The only real multi-homing is IPv4 - what works, does not > work and scale and does not scale. Its worth progressing > > Iljitsch van Beijnum: no experience that it does not scale > > Vince Fuller: Disagree - we know what does not scale from experience. > > Sean: keep the document? > > ** Humming to keep it in the charter. > > ** Vince Fuller volunteered to review Joe Abley's Draft. > > Kurtis Lindqvist: > > How to move this forward... There are a number of proposals made and > we > can't adopt them all as WG items. There is a proposal grouping (4) > from > the WGs, based on a single-link (NAROS), Mobile, rest as bottom up, > or > do what we already have. Propose to cull them down in terms of > numbers > and move them forward as documents before spending WG time on this. > DO > we want to stick with a single outcome or multiple solutions. Should > we > work in parallel with evaluation or serial? The mailer shows some > diversity of view as to how to do this. Is there a WG consensus > emerging > here? > > Christian Huitema: there is not that much difference between these > approaches. MobileIP is an instantiation of what the design team > called > 'big'. The separation of locator to identifier is a special case of > multiaddressing. The identifier is pretty much a home address, and in > this context you can recycle the MobileIP work, including associating > checking. It is entirely possible to design a path using > multiaddressing > using optimizations with mobile IP and consider a path in which we > create a virtual address realm of identifier as one of the multi- > addressing option - this is a simple movement without delaying > anything > on the way. > > Erik Nordmark: So you were comparing mobile IP with the big approach on > the slides - but that's not what the design team was talking about. > Mobile IP all used addresses that are used interchangeably and its > stitched together using tunnel. 'big' is different here - the > identifiers are not packet forwarding targets, and that's the > distinction between this approach and mobileIP. There is useful > mobile > IP technology , but it IS different > > Christian Huitema: On the reason why I claimed this was the same > problem > it is in fact possible to send a packet to an identifier using a > distributed hash table technology. You send a packet to the > identifier > without ever mapping it to an address by forwarding it on another > layer. > This is equivalent to multi-homing with another address. > > Kurtis Lindqvist: The classification was not a technical one - we were > simply wanting to limit the number of proposals coming to the WG. If > there was a 2nd design team working on this other approach then this > is > something that we are looking for > > Matsakata Ohta: mobile IPv6 is hopeless and broken. It has timeout of > 30 > second to switchover which is most cases too long. Its server based > not > host based. It is tunneling. (?) > > Brian Carpenter; lets not debate mobile IPv6. I wanted to say that I'm > on > the tunnel side of the debate with the design team is that its a fast > way to do id / locator separation and we need to put V1 of an id-to- > locator mapping and the rest is straightforward. Did no clean up the > meaning of multiaddressing. > > Sean Doran: Christian would be a good leader for the mobile IP / > multiaddressing approach design team. If they converge then great, if > not then lets understand it. > > Randy Bush: write up proposals and allow us to compare them. > > Christian Huitema: part of the reasons I gave the feedback is that I > don't > believe that the justification for separation is all that high. 1 > reason > is multi-addressing does not work, and we need feedback on this > claim to > understand it. The other reason is an API issue and going into an > architecture rewrite due to an API issue appears to be over the top. > > Matsakata Ohta: a name should lookup to locators - you don't need to > use > identifier middle step. we don't need to much mapping. > > Erik Nordmark: on the motivation for the split. The current tools we > have > on the table is pass from routing to apps, and applications can't > cope. > Architecturally its a mistake. This additional layer is useful and > helps > us scale. This is a similar argument with site-locals in V6. > > Kurtis Lindqvist: Can we expect the design team to include this? > > Lixia: what is an identifier? What does it identify? > > Erik Nordmark: Its called "stack" by the NSRG work. To be determined. > > Brian Carpenter: it is exactly a NSRG "stack" > > Lixia: evidence that multi-homing does not work? > > Iljitsch van Beijnum: There are combinations of selection of source and > destination that do not support a connection. Applications are > expected > to work across multiple addresses for 'self' and 'remote'. You don't > want to solve this in every app, and doing this in 1 point is the IP > layer in terms of the design team choice. > > Lixia: As of today this is not clear. Lets get some facts on this. > > Iljitsch van Beijnum: location and identifier in the packet could > improve > something. > > Matsakata Ohta: (8+8) a host accepts a packet with the low order 64 > bits > matching the local identifier. API is not an issue. > > Christian Huitema: apps do handle multiple addresses - VPNS, etc. Apps > do > have awareness today. > > Sean McCLeary: Address the issue of identifier / locator association. > There are other mechanisms for association that we can use. This > could > be a security association in some form. Keeping these separate is > good - > you don't care what the locator is as long as it provides confidence > about remote identity > > Erik Nordmark: Its not proveable multi-addressing does not work. The > choice appears to be 'add another layer of indirection" or "push it > to > the apps layer". Also if you apply IPSEC all the time then you don't > care about the addresses in every packet as you already have an IPsec > association. > > Vince Fuller: This address mapping today is NOT a form of security, and > the routing system does not and will not solve this, and the > ID/locator > split makes the problem more apparent, not any worse. The confusion > over > the ID/locator split is a consequence of growing up in a schizo > world of > addresses, and we simply have not thought about using them > separately. > Its a TCP identifier in the TCP protocol. The ISO OSI model did > separate > transport and network. Overload addresses don't work well. You cannot > change the underlying addresses because they are bound in transport! > The > agenda item is that of changing the transport layer. What really > needs > here is a richer transport layer, and using the identifier to hide > this > from the upper layers. Common usage is to bind an id to a host. Is > this > correct? > > Christian Huitema: SCTP shows that transport can be designed to handle > more than one address. Having an identifier for a session is claimed > by > Christian to be more useful than having an identifier for a host. > > Pekka Nikander: Much of this discussion is getting well beyond the > charter. Security is not just identification - its also denial of > service. There is a mobile IPv6 security background draft that > explores > this topic. > > Sean McCleary: Using identifiers to identify hosts rather than > interfaces. > It is common practices to assign addresses to loop back addresses to > get > this explicit host association. This is also a virtual hosting > technique. > > Erik Nordmark: Having this additional identifier that is not a domain > name > and not a locator is something we need to take really seriously. > > Brian Carpenter: There is an incorrect view that the name is the > identifier. We don't need a repeat of 9 drafts like Monday with a > beauty > parade. There are probably 3 proposals to sketch out > - design team approach > - mobileIP > - another multi-addressing that is neither of the above > > Erik Nordmark: to early to cut the proposals when we don't appear to > understand this space well enough. The ID/loc has security and > mapping > issues - how do the practical pieces fit together? > > Sean: You are saying: Please identify when you are making a trade-off- > and > what the trade-off may actually be. > > Iljitsch van Beijnum: Propose to concentrate on the design team and > look > at other approaches in a manner that is relative to the design team > output. The consider whether we work on many in parallel, or focus > the > WG activity. > > Kurtis Lindqvist: There is some need to aggregate these drafts right > now - > we need less rather than more. > > ** Christian Huitema to accept a role in a second design team > > Christian Huitema: willing to accept the 'other' design team proposal. > There were 4 drafts that were in the context of this multi-addressing > proposal. There is actually a difference in philosophy here - > Christian > claims the multi-address proposal as being incremental, and that it > requires no major new piece of software or new infrastructure. The > locator / identifier split is a major impact on the stacks, it is > claimed. It is claimed that this will take large amounts of time to > develop. It is claimed that the loc/id approach is much longer term > in > practice. > > Kurtis Lindqvist: Thanks Christian to accept to lead the design team. > We > need some more work on the part of the design teams to assess the > designs and their impact. > > > Peter Lothberg: Claim that this does not solve the routing problem. > There > is an assumption of separation. Lets trash V6 and collect > requirements > and start over. > > Erik Nordmark: would like to avoid competing proposals - there is a > difference of incrementalism and architecture differences. The > competition approach is not the best way to get mindshare across the > group. > > Kurtis Lindqvist: the design team does need to produce text to allow > us to > look at it closely. > > Iljitsch van Beijnum: Words of caution about heading off into an > entirely > new direction. > > Kurtis Lindqvist: we need to get the other approach documented to a > state > that they are comparable. There is nothing from the design team as > yet > and nothing at all from the other group to write up an approach. > > Sean: there is value in looking at various ways of undertaking > trade-offs > here, and this approach is of value to the effort. > > > > -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPxZS4qarNKXTPFCVEQKOWwCfQApi0/okQgr2jVpfdwLWNYLtczwAoKyy LBt9pzL7MjrlpvLlys0QnwF5 =ryIW -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Jul 17 04:16:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22346 for ; Thu, 17 Jul 2003 04:16:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19d3vW-000Doj-6R for multi6-data@psg.com; Thu, 17 Jul 2003 08:15:46 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.14) id 19d3vR-000Dno-Vd for multi6@ops.ietf.org; Thu, 17 Jul 2003 08:15:42 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h6H8F6R29740; Thu, 17 Jul 2003 10:15:06 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h6H8DSof048162; Thu, 17 Jul 2003 10:13:34 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200307170813.h6H8DSof048162@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: lek cc: Cedric de Launois , multi6@ops.ietf.org Subject: Re: Source address selection in IPv6 multihomed multi-addressed sites In-reply-to: Your message of Thu, 17 Jul 2003 14:27:11 +0700. Date: Thu, 17 Jul 2003 10:13:28 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: I wonder in any solution impling source address based routing that is it possible to use routing header instead of using source address based routing. If it could, I think using routing header is easier than source address based routing. => you seem to like the second meaning of "source routing"... IMHO we don't want to put the decision in the hands of hosts (in this case it should be easier to use the "right" source address) as the routing header is end-to-end. In fact, routing headers are well suit for another class of problems: policy routing, i.e., one may put the anycast address of a transit ISP in a routing header in order to enforce the path though this ISP. Regards Francis.Dupont@enst-bretagne.fr PS: cf. RFC 2526. BTW the last time I checked the support of IPv6 subnet anycast addresses in common routers was very bad. From owner-multi6@ops.ietf.org Thu Jul 17 04:21:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22547 for ; Thu, 17 Jul 2003 04:21:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19d40I-000E4d-Di for multi6-data@psg.com; Thu, 17 Jul 2003 08:20:42 +0000 Received: from [218.123.132.56] (helo=yakitori.no-ip.com ident=qmailr) by psg.com with smtp (Exim 4.14) id 19d40F-000E4E-AX for multi6@ops.ietf.org; Thu, 17 Jul 2003 08:20:39 +0000 Received: (qmail 22388 invoked by uid 0); 17 Jul 2003 08:20:32 -0000 Received: from unknown (HELO dekisugi) (torus@81.160.230.51) by yahoobb218123132056.bbtec.net with SMTP; 17 Jul 2003 08:20:32 -0000 Message-ID: <034701c34c3c$4893f270$33e6a051@dekisugi> From: "Kenji Ohira" To: "Cedric de Launois" Cc: References: <3F156970.6050404@info.ucl.ac.be> Subject: Re: Source address selection in IPv6 multihomed multi-addressed sites Date: Thu, 17 Jul 2003 17:20:24 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_10,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Cedric, ----- Original Message ----- From: "Cedric de Launois" Subject: Source address selection in IPv6 multihomed multi-addressed sites > I believe this problem needs to be resolved to get > a complete IPv6 multi-addressing multihoming solution. > We assume here that the providers perform ingress > filtering. > I'm here only looking to solutions where the source > address selection is not made by applications, but it > is done "automagically". However, for all these solutions, > it is possible to imagine some mechanism where the > applications can overload the automatic behaviour. First of all, I think that source address selection should be made by each application/transport layer. > Here is my understanding of the different solutions > proposed. > > * A solution is to perform source address based routing > inside the multihomed site. The packets are always > routed to the site exit router corresponding to the > source address used. > > Pros: - no new option/protocol > - no modification to hosts > - no tunnel > - routing efficiency (dumb routing) ? > > Cons: - possibly very bad load-balancing if all the > hosts choose the same source address (and this > is what they'll do with RFC3484 !) + > no way to engineer the traffic if no additionnal > mechanism is used > - source address based routing has probably > much more implications than what it is > expected. This needs to be studied further. > > My point of view : maybe source address based routing > is not something desirable. Anyway, source address based > routing alone is not sufficient. We are interested in application-level load sharing more than that of site-level. I think that it is related to QoS issue, too. If an application wants to use all bandwidth of all external connection, it is able by selecting all address which the host has. If QoS parameters of each path are differ, an application can select the best suited path which it needs. If an application has no special requirements for any QoS parameters, the application can leave this selection to transport layer protocol as like as SCTP. In this case, at the timing of establishing a connection, transport layer protocols on both end hosts negotiate all addresses which each host has, and each host select the best pair of src/dst addresses in according to RTT. As another solution, an application or a protocol of transport layer can select a path in according to the longest match between source address and destination address. In order to talk about this, I talked about 3-level hierarchical network model. As more other solution, an application or a protocol of transport layer can select route in according to the external database as like as NAROS. Anyway, a selection of source address can be and should be resolved in layer 4 or above. For this reason, IP layer should be simple as possible in order to select correct site-exit router which is corresponding to a source address selected in layer 4 or above. July 17, 2003 (JST +0900) ---- Kenji Ohira Graduate School of Informatics, Kyoto University, JAPAN mailto: torus@tori.cc / ohira@net.ist.i.kyoto-u.ac.jp From owner-multi6@ops.ietf.org Thu Jul 17 05:26:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25870 for ; Thu, 17 Jul 2003 05:26:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19d4zv-000HY0-7a for multi6-data@psg.com; Thu, 17 Jul 2003 09:24:23 +0000 Received: from [194.196.100.235] (helo=d12lmsgate-2.de.ibm.com) by psg.com with esmtp (Exim 4.14) id 19d4zs-000HVr-KN for multi6@ops.ietf.org; Thu, 17 Jul 2003 09:24:20 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6H9Na9d054812 for ; Thu, 17 Jul 2003 11:23:42 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6H9Moce096412 for ; Thu, 17 Jul 2003 11:22:51 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA24226 for ; Thu, 17 Jul 2003 11:22:48 +0200 Message-ID: <3F166AEE.6F6DA106@hursley.ibm.com> Date: Thu, 17 Jul 2003 11:22:54 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Source address selection in IPv6 multihomed multi-addressed sites References: <3F156970.6050404@info.ucl.ac.be> <034701c34c3c$4893f270$33e6a051@dekisugi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.6 required=5.0 tests=BAYES_20,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kenji Ohira wrote: ... > First of all, I think that source address selection should be made by each > application/transport layer. As I and Keith Moore and Christian Huitema have been trying to say, this is not realistic as a general case. In some special cases we can expect upper layers to be able to do this, but it has to be handled by default in the IP layer. Brian From owner-multi6@ops.ietf.org Thu Jul 17 08:37:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03941 for ; Thu, 17 Jul 2003 08:37:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19d7y9-0002M9-Es for multi6-data@psg.com; Thu, 17 Jul 2003 12:34:45 +0000 Received: from [81.160.235.37] (helo=laptop2.ietf57.telekom.at) by psg.com with esmtp (Exim 4.14) id 19d7xw-0002LU-6x for multi6@ops.ietf.org; Thu, 17 Jul 2003 12:34:32 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.ietf57.telekom.at (8.12.9/8.10.2) with ESMTP id h6HCYPk1001655; Thu, 17 Jul 2003 14:34:26 +0200 (CEST) Date: Thu, 17 Jul 2003 14:34:21 +0200 Subject: Re: More random and not so random thoughts Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <3BB28B4C-B78D-11D7-9CB7-00039388672E@muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.0 required=5.0 tests=BAYES_10,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I suppose it would be a good idea to get a working definition of > "multiaddressing". I think the idea is that a host gets more than one > address. At some point this host will start emitting packets to the > network. The most basic problem that we must solve in order for this > to work is the source address selection problem. This seem to be on the plate for more than one working group at the moment, and I would guess that the IETF needs to do some work here. I think I can guess Randy's comment : "As long as work is being done it doesn't matter where it is". But I still think this is the grey zone for belonging here. If so, I think we need to convince some applications people to start following this WG. > Something better than RFC 3484 for the destination address would be > very useful too. See above. > I think we can address this separately from whatever else we're going > to do. So by all means, work such as NAROS should continue. Agree, see above. > IP: not so bad and not so good > > - this can be a general mechanism, do it once, solve the problem > forever > - possibility of offloading processing to middlebox for policy, > efficiency or speedy deployment > > Ideally, we could start by implementing this in middleboxes. Yes, > middleboxes suck but doing multihoming in the face of restrictive RIR > policies and strange filters in far away networks isn't much fun > either. RIR policies are set by the community, not by the RIRs for their own sake. > Then everything is implemented in the OSes. Now there is a tradition > in Unix where TCP and IP are in practice completely comingled. So even > though we define this mechanism to work at the IP layer, TCP > implementations could easily incorporate this and start doing *really* > interesting things such as load balancing a single session over > multiple paths. > > And if we're careful when defining all of this, it should be possible > to drop in a new namespace if and when this is considered desirable. So you are arguing for adding a new "abstraction" layer in the architecture? > Christian says implementing this would turn OSes upside down. But I > simply don't see this. It seems to me that this could be entirely > contained to the (TCP/)IP stack. Applications simply revert to IPv4 > behavior where they connect to a single address and if it is possible > to set up the session, it will happen, and if not, the connection > fails. No need to do anything complex. The unanswered question is how much do we want to / can we / dare we to change in the architecture in one go. > About the roadmap/more desing teams thing: I'm afraid of a situation > where a good core idea doesn't take some limitations in consideration > so the resulting proposal is flawed. It looks like this is already the > case with e2e/lin6, but I have to read a bit more about those before I > can say anything conclusive here. Hopefully the chairs can figure out > a way to avoid this from happening. > The point me and Sean tried to make is that people will have their views and ideas on the solution of a specific problem, if there is one, two or ten design teams. For us as chairs, it is however easier to handle if these views are expressed grouped in single drafts, rather than as comments and individual drafts per each person. So I see your concerns, but I don't see how a second design team changes anything. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPxaXz6arNKXTPFCVEQLPzACfZHskdIC7UUpcuFBclpHkEaIGVbIAoM9W psCxL3tikzZtIC1K51rBcrHb =ZkM0 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Jul 17 11:03:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10741 for ; Thu, 17 Jul 2003 11:03:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dAGD-000Aif-3C for multi6-data@psg.com; Thu, 17 Jul 2003 15:01:33 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19dAG9-000Ag4-NC for multi6@ops.ietf.org; Thu, 17 Jul 2003 15:01:29 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Jul 2003 08:00:59 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 17 Jul 2003 08:00:50 -0700 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 17 Jul 2003 08:00:58 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 17 Jul 2003 08:00:20 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 17 Jul 2003 08:00:32 -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.0); Thu, 17 Jul 2003 08:01:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.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: Source address selection in IPv6 multihomed multi-addressed sites Date: Thu, 17 Jul 2003 07:31:36 -0700 Message-ID: Thread-Topic: Source address selection in IPv6 multihomed multi-addressed sites Thread-Index: AcNMRdsWDpvZlZ1RRbmuUkMjJbExMQAKkWsU From: "Christian Huitema" To: "Brian E Carpenter" , X-OriginalArrivalTime: 17 Jul 2003 15:01:06.0620 (UTC) FILETIME=[3FC37FC0:01C34C74] X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I certainly did not say that the choice should be handled "by default in = the IP layer". I said that it is typically handled by the TCP-IP stack, = after the application binds to ANY. But TCP-IP stack !=3D IP layer. The = IP layer only starts operating when both source and destination have = been chosen.. ________________________________ From: owner-multi6@ops.ietf.org on behalf of Brian E Carpenter Sent: Thu 7/17/2003 2:22 AM To: multi6@ops.ietf.org Subject: Re: Source address selection in IPv6 multihomed multi-addressed = sites Kenji Ohira wrote: ... > First of all, I think that source address selection should be made by = each > application/transport layer. As I and Keith Moore and Christian Huitema have been trying to say, this is not realistic as a general case. In some special cases we can expect upper layers to be able to do this, but it has to be handled by default in the IP layer. Brian From owner-multi6@ops.ietf.org Thu Jul 17 12:18:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12762 for ; Thu, 17 Jul 2003 12:18:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dBR2-000EZw-SM for multi6-data@psg.com; Thu, 17 Jul 2003 16:16:48 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.14) id 19dBQy-000EZe-6P for multi6@ops.ietf.org; Thu, 17 Jul 2003 16:16:44 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h6HGGgtU009930; Thu, 17 Jul 2003 12:16:42 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h6HGGfNP009929; Thu, 17 Jul 2003 12:16:41 -0400 Date: Thu, 17 Jul 2003 12:16:41 -0400 From: "J. Noel Chiappa" Message-Id: <200307171616.h6HGGfNP009929@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Fwd: Minutes / Notes Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Kurt Erik Lindqvist > Please find attached Geoff minutes from yesterday. Please send comments > to me _off list_ and I will add them. I have a few technical (not editorial) comments on some points in the minutes, which are therefore of general interest... > Iljitsch van Beijnum: the focus is on TCP and you can't have a TCP > that switches addresses mid-flow because you don't have API support > Christian Huitema: The reason here is the protocol specification of TCP, > not the API This is only important if you want TCP connections to be able to survive having an incoming link fail (i.e. the address on the local end becomes unreachable to the rest of the network). This may not be an important goal (e.g. the typical web site wouldn't care). > Iljitsch van Beijnum: Obviously we can modify TCP without the API but > we see modifying the network layer > Christian Huitema: The socket API constrains the solution you are > saying that the socket API is the problem. Well, actually you could modify the protocol without modifying the API: the "address" handed back and forth across between the application and network layer(s) would be a "token" using the same syntax as an IP address, which translates internally in the network layer to the appropriate address(es) for the far end. The problem, of course, is that the "token" is of only local scope to the host, and thus can't be handed to third parties to allow them to contact the other end (think the same problem as NAT). That's easy to fix - you only hand around the name you start with (e.g. DNS - again, same fix as to this problem in NAT). There is one issue with modifying TCP (it's a pretty easy upgrade - you define a TCP option which allows you to specify additional addresses and/or switch to a different address), which is that with an unmodified TCP on the other end, you then don't have this capability. But you may not care (see preceding point). Noel From owner-multi6@ops.ietf.org Thu Jul 17 12:46:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13504 for ; Thu, 17 Jul 2003 12:46:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dBsx-000Flv-BU for multi6-data@psg.com; Thu, 17 Jul 2003 16:45:39 +0000 Received: from [18.26.0.55] (helo=cordelia.lcs.mit.edu) by psg.com with esmtp (Exim 4.14) id 19dBsu-000Flg-Q6 for multi6@ops.ietf.org; Thu, 17 Jul 2003 16:45:36 +0000 Received: from cordelia.lcs.mit.edu (localhost [127.0.0.1]) by cordelia.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h6HGja03057269 for ; Thu, 17 Jul 2003 12:45:36 -0400 (EDT) (envelope-from yxw@cordelia.lcs.mit.edu) Date: Thu, 17 Jul 2003 12:45:36 -0400 Message-ID: From: Xiaowei Yang To: multi6@ops.ietf.org Subject: Re: Source address selection in IPv6 multihomed multi-addressed sites References: <3F156970.6050404@info.ucl.ac.be> User-Agent: Wanderlust/2.8.1 (Something) Emacs/21.2 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-10.2 required=5.0 tests=BAYES_20,QUOTE_TWICE_1,REFERENCES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > > * A sixth solution is that a host tries to detect > by itself which source address to use. A proposition > is that a host maintain by itself one or more full BGP > tables so that it can deduce the source address to use. > > Pro : no tunnel > Cons: - waste of computer resources (how much ?) > - no easy configuration I do not see why a host needs to maintain the full BGP tables. For source address selection, it seems to me a host only needs to know the provider-level route a source address represents, i.e., the chain of providers that allocate a source address to the site/host. Suppose the source address allocation chain on average has a depth of three. A network on average takes source addresses from five providers. Then the number of providers concerning a site's source addresses is about 5^3. If a graph is used to represent these providers, the resources required to store this graph and update it should be much less than keeping an updated full BGP table that has 100,000+ entries. The destination address selection is also a problem. To send the first packet to a multi-homed destination, a host needs to pick a valid destination address. This picking is less important because once the first packet reaches the destination, the destination host may switch to a different address in its reply packets that fits its QoS requirements. Therefore, a host may random pick a destination address. If it doesnot work, the host could try the a different destination address. Obtaining the provider information concerning source addresses of a host requires a new network service. Source address selection implies provider selection, which has the potential to increase competition among providers and discipline the ISP market. From this aspect, it is important for a user to make an informed choice rather than a random choice. Thus, the effort to provide a new network service to disseminate provider information may be worthwhile. My thesis work is right on this topic. If anyone is interested, a short paper describing my work can be found at http://www.isi.edu/newarch/DOCUMENTS/yang.nira.pdf Xiaowei From owner-multi6@ops.ietf.org Thu Jul 17 13:40:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14821 for ; Thu, 17 Jul 2003 13:40:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dCi6-000I92-Je for multi6-data@psg.com; Thu, 17 Jul 2003 17:38:30 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.14) id 19dCi2-000I7k-Gg for multi6@ops.ietf.org; Thu, 17 Jul 2003 17:38:26 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id C7C343446C; Thu, 17 Jul 2003 10:55:18 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6HHbqYB015654; Thu, 17 Jul 2003 10:37:52 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: Fwd: Minutes / Notes Date: Thu, 17 Jul 2003 10:37:52 -0700 Message-ID: Thread-Topic: Fwd: Minutes / Notes Thread-Index: AcNMgE1/guM3dzikQ5yH9QFoOPS51QACN/+Q From: "Tony Li" To: "J. Noel Chiappa" , X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Noel, | This is only important if you want TCP connections to be=20 | able to survive | having an incoming link fail (i.e. the address on the=20 | local end becomes | unreachable to the rest of the network). This may not be=20 | an important goal | (e.g. the typical web site wouldn't care). I believe that the WG has come to rough consensus that this is, in fact, an important goal for us to solve. There are=20 numerous practical applications that drive this. More generally, we (IETF, vendors) are being asked to make the Internet safe for "mission critical" applications and having broken TCP connections is simply unacceptable. Many applications today are being outsourced: backups, storage, business applications, interactions within an 'extra-net', etc. Tony From owner-multi6@ops.ietf.org Thu Jul 17 14:10:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16070 for ; Thu, 17 Jul 2003 14:10:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dDBl-000JdY-B6 for multi6-data@psg.com; Thu, 17 Jul 2003 18:09:09 +0000 Received: from [194.196.100.236] (helo=d12lmsgate-3.de.ibm.com) by psg.com with esmtp (Exim 4.14) id 19dDBg-000JcV-Vb for multi6@ops.ietf.org; Thu, 17 Jul 2003 18:09:05 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6HI8XZG043326; Thu, 17 Jul 2003 20:08:33 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6HI8Wce270166; Thu, 17 Jul 2003 20:08:32 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id UAA37032; Thu, 17 Jul 2003 20:08:27 +0200 Message-ID: <3F16E621.2DF11C88@hursley.ibm.com> Date: Thu, 17 Jul 2003 20:08:33 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Christian Huitema CC: multi6@ops.ietf.org Subject: Re: Source address selection in IPv6 multihomed multi-addressed sites References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-28.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian, I'm sorry to have over-interpreted what you said. I should probably have written "...should be handled by default below the socket API." Brian Christian Huitema wrote: > > I certainly did not say that the choice should be handled "by default in the IP layer". I said that it is typically handled by the TCP-IP stack, after the application binds to ANY. But TCP-IP stack != IP layer. The IP layer only starts operating when both source and destination have been chosen.. > > ________________________________ > > From: owner-multi6@ops.ietf.org on behalf of Brian E Carpenter > Sent: Thu 7/17/2003 2:22 AM > To: multi6@ops.ietf.org > Subject: Re: Source address selection in IPv6 multihomed multi-addressed sites > > Kenji Ohira wrote: > ... > > First of all, I think that source address selection should be made by each > > application/transport layer. > > As I and Keith Moore and Christian Huitema have been trying to say, > this is not realistic as a general case. In some special cases we can > expect upper layers to be able to do this, but it has to be handled > by default in the IP layer. > > Brian From owner-multi6@ops.ietf.org Thu Jul 17 14:37:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17083 for ; Thu, 17 Jul 2003 14:37:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dDci-000KwH-2Q for multi6-data@psg.com; Thu, 17 Jul 2003 18:37:00 +0000 Received: from [81.160.235.37] (helo=laptop2.ietf57.telekom.at) by psg.com with esmtp (Exim 4.14) id 19dDcX-000KvB-MH for multi6@ops.ietf.org; Thu, 17 Jul 2003 18:36:51 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.ietf57.telekom.at (8.12.9/8.10.2) with ESMTP id h6HIaXk1001807; Thu, 17 Jul 2003 20:36:36 +0200 (CEST) Date: Thu, 17 Jul 2003 20:36:26 +0200 Subject: Multi6 webpages Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Brian Carpenter , Sean Doran To: multi6@ops.ietf.org From: Kurt Erik Lindqvist Content-Transfer-Encoding: 7bit Message-Id: <931FA907-B885-11D7-A9AB-000393A638B2@kurtis.pp.se> X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-14.8 required=5.0 tests=BAYES_01,PGP_SIGNATURE,UPPERCASE_25_50,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The WG now have a web-page with all the presentations as well as Brians presentation from the IAB open architecture meeting. Link is http://ops.ietf.org/multi6. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPxbsraarNKXTPFCVEQIIxACff95dw8P8YLcE5EfqREqFCsvKoVsAnRMX Fq7aXq46L0wMn1KgLh3m528N =hMp7 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Jul 17 15:03:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18018 for ; Thu, 17 Jul 2003 15:03:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dE1g-000MME-5Y for multi6-data@psg.com; Thu, 17 Jul 2003 19:02:48 +0000 Received: from [199.67.7.205] (helo=maunakea.aafes.com) by psg.com with esmtp (Exim 4.14) id 19dE1d-000MLz-UX for multi6@ops.ietf.org; Thu, 17 Jul 2003 19:02:46 +0000 Received: (from daemon@localhost) by maunakea.aafes.com (8.12.9/8.12.9) id h6HJ2d7o073775; Thu, 17 Jul 2003 14:02:39 -0500 (CDT) Received: from hqmailbh02.aafes.com(192.168.32.54) via SMTP by maunakea.aafes.com, id smtpdsxBzbu; Thu Jul 17 14:02:30 2003 Received: from HQMAILHA.aafes.com ([192.168.32.21]) by hqmailbh02.aafes.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Jul 2003 14:01:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Fwd: Minutes / Notes Date: Thu, 17 Jul 2003 14:01:16 -0500 Message-ID: Thread-Topic: Fwd: Minutes / Notes Thread-Index: AcNMgE1/guM3dzikQ5yH9QFoOPS51QACN/+QAAMh/TA= From: "Grovesteen, Harold" To: "Tony Li" , "J. Noel Chiappa" , X-OriginalArrivalTime: 17 Jul 2003 19:01:16.0644 (UTC) FILETIME=[CCCEAA40:01C34C95] X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable YES! -----Original Message----- From: Tony Li [mailto:Tony.Li@procket.com] Sent: Thursday, July 17, 2003 12:38 PM To: J. Noel Chiappa; multi6@ops.ietf.org Subject: RE: Fwd: Minutes / Notes Noel, | This is only important if you want TCP connections to be=20 | able to survive | having an incoming link fail (i.e. the address on the=20 | local end becomes | unreachable to the rest of the network). This may not be=20 | an important goal | (e.g. the typical web site wouldn't care). I believe that the WG has come to rough consensus that this is, in fact, an important goal for us to solve. There are=20 numerous practical applications that drive this. More generally, we (IETF, vendors) are being asked to make the Internet safe for "mission critical" applications and having broken TCP connections is simply unacceptable. Many applications today are being outsourced: backups, storage, business applications, interactions within an 'extra-net', etc. Tony From owner-multi6@ops.ietf.org Fri Jul 18 02:12:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17589 for ; Fri, 18 Jul 2003 02:12:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dOQA-000Pkj-He for multi6-data@psg.com; Fri, 18 Jul 2003 06:08:46 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19dOQ7-000PkS-VB for multi6@ops.ietf.org; Fri, 18 Jul 2003 06:08:44 +0000 From: Masataka Ohta Message-Id: <200307180556.OAA14096@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA14096; Fri, 18 Jul 2003 14:56:30 +0900 Subject: Re: Source address selection in IPv6 multihomed multi-addressed sites In-Reply-To: <3F156970.6050404@info.ucl.ac.be> from Cedric de Launois at "Jul 16, 2003 05:04:16 pm" To: Cedric de Launois Date: Fri, 18 Jul 2003 14:56:29 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-8.1 required=5.0 tests=BAYES_10,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Cedric; > Any comment/suggestion/correction ? You completely misunderstand the role of BGP. See my draft stating: However, to enable source address filtering to discard packets with source addresses not belonging to an ISP, it is useful to enable a host, not some intelligent intermediate router, select a source address compatible with an outgoing ISP. For that purpose, intra domain routing protocols or something like that should maintain routing table entries with not only preference values of an external routes, but also proper prefixes to be selected for source addresses, if the entries are chosen by a host. It should be noted that it is already doable with the current OSPF spec. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jul 18 02:17:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18067 for ; Fri, 18 Jul 2003 02:17:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dOXq-00008p-GQ for multi6-data@psg.com; Fri, 18 Jul 2003 06:16:42 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19dOXn-00008U-Tz for multi6@ops.ietf.org; Fri, 18 Jul 2003 06:16:40 +0000 From: Masataka Ohta Message-Id: <200307180605.PAA14146@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA14146; Fri, 18 Jul 2003 15:05:12 +0900 Subject: Re: Source address selection in IPv6 multihomed multi-addressed sites In-Reply-To: <3F166AEE.6F6DA106@hursley.ibm.com> from Brian E Carpenter at "Jul 17, 2003 11:22:54 am" To: Brian E Carpenter Date: Fri, 18 Jul 2003 15:05:12 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-11.9 required=5.0 tests=BAYES_10,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Brian; > > First of all, I think that source address selection should be made by each > > application/transport layer. > > As I and Keith Moore and Christian Huitema have been trying to say, > this is not realistic as a general case. In some special cases we can > expect upper layers to be able to do this, but it has to be handled > by default in the IP layer. IP layer can not select a destination address, though it can make a suggestion to the upper layers. Transport layer can not select a source address at all unless we are doing QoS routing. Ohira-san may be confused, because a scalable implementation of QoS routing (designed by me and others) is running around him. But, for most of you, it is extremely special. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jul 18 02:49:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19307 for ; Fri, 18 Jul 2003 02:49:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dP2u-0001nE-AO for multi6-data@psg.com; Fri, 18 Jul 2003 06:48:48 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19dP2q-0001n2-NQ for multi6@ops.ietf.org; Fri, 18 Jul 2003 06:48:45 +0000 From: Masataka Ohta Message-Id: <200307180640.PAA14351@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA14351; Fri, 18 Jul 2003 15:40:02 +0900 Subject: Re: Fwd: Minutes / Notes In-Reply-To: <200307171616.h6HGGfNP009929@ginger.lcs.mit.edu> from "J. Noel Chiappa" at "Jul 17, 2003 12:16:41 pm" To: "J. Noel Chiappa" Date: Fri, 18 Jul 2003 15:40:01 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Noel; > > Please find attached Geoff minutes from yesterday. Please send comments > > to me _off list_ and I will add them. > > I have a few technical (not editorial) comments on some points in the minutes, > which are therefore of general interest... A problem is that the minutes lacks discussioin on so many errors of Iljitsch's proposal that yo are repeating my points at the meeting (save TCP survivability as I said TCP is not IP, the Internet Protocol). > > Iljitsch van Beijnum: Obviously we can modify TCP without the API but > > we see modifying the network layer > > Christian Huitema: The socket API constrains the solution you are > > saying that the socket API is the problem. > > Well, actually you could modify the protocol without modifying the API: Yes. LIN6 was and still is implemented so, though it has other APIs. I said so at the meeting but the statement is missing from the draft minutes. > There is one issue with modifying TCP (it's a pretty easy upgrade - you > define a TCP option which allows you to specify additional addresses and/or > switch to a different address), which is that with an unmodified TCP on the > other end, you then don't have this capability. But you may not care (see > preceding point). It is a little more hard. If you have several addresses, TCP limitation on option length makes it not interoperable with unmodified TCP. You may use multiple exchanges of packets for carrying more addresses or for option length negotiation, which means extra amount of delay and additional complexity. An easy solution is to use separate address spaces (within 128 bit space of IPv6) for leagacy and new IPv6 hosts. Then, you can use larger header between new hosts. It is implemented and running. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jul 18 03:59:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21537 for ; Fri, 18 Jul 2003 03:59:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dQ8H-0004s1-E6 for multi6-data@psg.com; Fri, 18 Jul 2003 07:58:25 +0000 Received: from [194.196.100.238] (helo=d12lmsgate-5.de.ibm.com) by psg.com with esmtp (Exim 4.14) id 19dQ8D-0004qu-Il for multi6@ops.ietf.org; Fri, 18 Jul 2003 07:58:21 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6I7vnu5034116 for ; Fri, 18 Jul 2003 09:57:49 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6I7vnuP257378 for ; Fri, 18 Jul 2003 09:57:49 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA27990 for ; Fri, 18 Jul 2003 09:57:47 +0200 Message-ID: <3F17A881.1551B050@hursley.ibm.com> Date: Fri, 18 Jul 2003 09:57:53 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Fwd: Minutes / Notes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-28.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Well, this is one of the many "shoulds" in our agreed list of goals. Whether we can achieve this "should" simultaneously with enough of the others is very much an open question in my mind, and it's one of the reasons why we may end up with more than one solution. In some scenarios, this may be a dominant goal; in other scenarios, it may be unimportant. Brian "Grovesteen, Harold" wrote: > > YES! > > -----Original Message----- > From: Tony Li [mailto:Tony.Li@procket.com] > Sent: Thursday, July 17, 2003 12:38 PM > To: J. Noel Chiappa; multi6@ops.ietf.org > Subject: RE: Fwd: Minutes / Notes > > Noel, > > | This is only important if you want TCP connections to be > | able to survive > | having an incoming link fail (i.e. the address on the > | local end becomes > | unreachable to the rest of the network). This may not be > | an important goal > | (e.g. the typical web site wouldn't care). > > I believe that the WG has come to rough consensus that this is, > in fact, an important goal for us to solve. There are > numerous practical applications that drive this. More generally, > we (IETF, vendors) are being asked to make the Internet safe > for "mission critical" applications and having broken TCP > connections is simply unacceptable. Many applications today > are being outsourced: backups, storage, business applications, > interactions within an 'extra-net', etc. > > Tony From owner-multi6@ops.ietf.org Fri Jul 18 04:13:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22033 for ; Fri, 18 Jul 2003 04:13:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dQLN-0005d1-8j for multi6-data@psg.com; Fri, 18 Jul 2003 08:11:57 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.14) id 19dQLA-0005bn-0Y for multi6@ops.ietf.org; Fri, 18 Jul 2003 08:11:44 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id CA05034441; Fri, 18 Jul 2003 01:28:35 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6I8BDYB011621; Fri, 18 Jul 2003 01:11:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: Minutes / Notes Date: Fri, 18 Jul 2003 01:11:13 -0700 Message-ID: Thread-Topic: Minutes / Notes Thread-Index: AcNNA6jcT6JEaX/oSaaRntbXwdOsIgAAFRhg From: "Tony Li" To: "Brian E Carpenter" , X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Brian, If we do not fix this, then we can just close up shop and go home, because the business world is NOT going to accept a solution that doesn't fulfill this. They would rather use IPv4 and PI addresses. Tony | -----Original Message----- | From: Brian E Carpenter [mailto:brian@hursley.ibm.com]=20 | Sent: Friday, July 18, 2003 12:58 AM | To: multi6@ops.ietf.org | Subject: Re: Minutes / Notes | =20 | =20 | Well, this is one of the many "shoulds" in our agreed list | of goals. Whether we can achieve this "should" simultaneously | with enough of the others is very much an open question | in my mind, and it's one of the reasons why we may end up | with more than one solution. In some scenarios, this may | be a dominant goal; in other scenarios, it may be unimportant. | =20 | Brian | =20 | "Grovesteen, Harold" wrote: | >=20 | > YES! | >=20 | > -----Original Message----- | > From: Tony Li [mailto:Tony.Li@procket.com] | > Sent: Thursday, July 17, 2003 12:38 PM | > To: J. Noel Chiappa; multi6@ops.ietf.org | > Subject: RE: Fwd: Minutes / Notes | >=20 | > Noel, | >=20 | > | This is only important if you want TCP connections to be | > | able to survive | > | having an incoming link fail (i.e. the address on the | > | local end becomes | > | unreachable to the rest of the network). This may not be | > | an important goal | > | (e.g. the typical web site wouldn't care). | >=20 | > I believe that the WG has come to rough consensus that this is, | > in fact, an important goal for us to solve. There are | > numerous practical applications that drive this. More generally, | > we (IETF, vendors) are being asked to make the Internet safe | > for "mission critical" applications and having broken TCP | > connections is simply unacceptable. Many applications today | > are being outsourced: backups, storage, business applications, | > interactions within an 'extra-net', etc. | >=20 | > Tony | =20 | =20 From owner-multi6@ops.ietf.org Fri Jul 18 04:13:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22055 for ; Fri, 18 Jul 2003 04:13:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dQMH-0005eh-Fx for multi6-data@psg.com; Fri, 18 Jul 2003 08:12:53 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19dQME-0005eU-Vp for multi6@ops.ietf.org; Fri, 18 Jul 2003 08:12:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6I8Clj16337; Fri, 18 Jul 2003 11:12:47 +0300 Date: Fri, 18 Jul 2003 11:12:46 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: multi6@ops.ietf.org Subject: Re: Fwd: Minutes / Notes In-Reply-To: <3F17A881.1551B050@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 18 Jul 2003, Brian E Carpenter wrote: > Well, this is one of the many "shoulds" in our agreed list > of goals. Whether we can achieve this "should" simultaneously > with enough of the others is very much an open question > in my mind, and it's one of the reasons why we may end up > with more than one solution. In some scenarios, this may > be a dominant goal; in other scenarios, it may be unimportant. I agree that handling broken connections is useful. However, I also think that one must apply some reason here. For example, if you have have tunnels from two access routers to two ISP's ("site exit routers approach"), I don't think you have to care about connection survivability that much. ISPs' networks don't crash every other day (if they do, change the ISPs; we just can't design protocols to work around broken operational practices: that's going to fail, no matter what). Might happen a couple of times during the year, at most, but I'm not convinced that's necessarily a huge problem. > > -----Original Message----- > > From: Tony Li [mailto:Tony.Li@procket.com] > > Sent: Thursday, July 17, 2003 12:38 PM > > To: J. Noel Chiappa; multi6@ops.ietf.org > > Subject: RE: Fwd: Minutes / Notes > > > > Noel, > > > > | This is only important if you want TCP connections to be > > | able to survive > > | having an incoming link fail (i.e. the address on the > > | local end becomes > > | unreachable to the rest of the network). This may not be > > | an important goal > > | (e.g. the typical web site wouldn't care). > > > > I believe that the WG has come to rough consensus that this is, > > in fact, an important goal for us to solve. There are > > numerous practical applications that drive this. More generally, > > we (IETF, vendors) are being asked to make the Internet safe > > for "mission critical" applications and having broken TCP > > connections is simply unacceptable. Many applications today > > are being outsourced: backups, storage, business applications, > > interactions within an 'extra-net', etc. > > > > Tony > -- 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 Fri Jul 18 04:25:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22650 for ; Fri, 18 Jul 2003 04:25:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dQYG-0006LZ-8w for multi6-data@psg.com; Fri, 18 Jul 2003 08:25:16 +0000 Received: from [194.196.100.238] (helo=d12lmsgate-5.de.ibm.com) by psg.com with esmtp (Exim 4.14) id 19dQYC-0006I0-2Z for multi6@ops.ietf.org; Fri, 18 Jul 2003 08:25:12 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6I8Odu5041024; Fri, 18 Jul 2003 10:24:39 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6I8ObuP222066; Fri, 18 Jul 2003 10:24:37 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA45472; Fri, 18 Jul 2003 10:24:34 +0200 Message-ID: <3F17AEC8.5F0081B3@hursley.ibm.com> Date: Fri, 18 Jul 2003 10:24:40 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Tony Li CC: multi6@ops.ietf.org Subject: Re: Minutes / Notes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony, Yes, but you can't use the same argument for casual web browsing. BTW, this is why commercial message queueing systems exist; they can bridge reliable transactions over significant disconnects. Brian Tony Li wrote: > > Brian, > > If we do not fix this, then we can just close up shop and go home, > because the business world is NOT going to accept a solution that > doesn't fulfill this. They would rather use IPv4 and PI addresses. > > Tony > > | -----Original Message----- > | From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > | Sent: Friday, July 18, 2003 12:58 AM > | To: multi6@ops.ietf.org > | Subject: Re: Minutes / Notes > | > | > | Well, this is one of the many "shoulds" in our agreed list > | of goals. Whether we can achieve this "should" simultaneously > | with enough of the others is very much an open question > | in my mind, and it's one of the reasons why we may end up > | with more than one solution. In some scenarios, this may > | be a dominant goal; in other scenarios, it may be unimportant. > | > | Brian > | > | "Grovesteen, Harold" wrote: > | > > | > YES! > | > > | > -----Original Message----- > | > From: Tony Li [mailto:Tony.Li@procket.com] > | > Sent: Thursday, July 17, 2003 12:38 PM > | > To: J. Noel Chiappa; multi6@ops.ietf.org > | > Subject: RE: Fwd: Minutes / Notes > | > > | > Noel, > | > > | > | This is only important if you want TCP connections to be > | > | able to survive > | > | having an incoming link fail (i.e. the address on the > | > | local end becomes > | > | unreachable to the rest of the network). This may not be > | > | an important goal > | > | (e.g. the typical web site wouldn't care). > | > > | > I believe that the WG has come to rough consensus that this is, > | > in fact, an important goal for us to solve. There are > | > numerous practical applications that drive this. More generally, > | > we (IETF, vendors) are being asked to make the Internet safe > | > for "mission critical" applications and having broken TCP > | > connections is simply unacceptable. Many applications today > | > are being outsourced: backups, storage, business applications, > | > interactions within an 'extra-net', etc. > | > > | > Tony From owner-multi6@ops.ietf.org Fri Jul 18 11:12:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03527 for ; Fri, 18 Jul 2003 11:12:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dWnU-000NG1-Bw for multi6-data@psg.com; Fri, 18 Jul 2003 15:05:24 +0000 Received: from [208.185.30.208] (helo=buffoon.automagic.org ident=qmailr) by psg.com with smtp (Exim 4.14) id 19dWnQ-000NFh-BK for multi6@ops.ietf.org; Fri, 18 Jul 2003 15:05:20 +0000 Received: (qmail 77686 invoked by uid 0); 18 Jul 2003 15:05:19 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 18 Jul 2003 15:05:19 -0000 Date: Fri, 18 Jul 2003 11:05:17 -0400 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Brian E Carpenter , multi6@ops.ietf.org To: Pekka Savola From: Joe Abley In-Reply-To: Message-Id: <3E1678D6-B931-11D7-9A86-00039312C852@isc.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Jul 18, 2003, at 04:12 Canada/Eastern, Pekka Savola wrote: > ISPs' networks don't crash every other day (if they do, change the > ISPs; > we just can't design protocols to work around broken operational > practices: that's going to fail, no matter what). Might happen a > couple > of times during the year, at most, but I'm not convinced that's > necessarily a huge problem. This isn't about ISPs' networks "crashing" -- it's about transient changes in routing topology, which *do* happen with monotonous regularity (circuits fail, or take errors and have to be shut down; upstream providers fat-finger routing policy and stopping routes from propagating, etc). Also remember that the effects of a re-homing event can be felt several levels down; if your path to the DFZ is through three intermediate ASes, then you're three-times as likely to feel the impact of a re-homing event if the multihoming architecture presents an impact to be felt. In some countries, *all* the ISPs are two or three ASes away from the core. The fact that the perception today is that "ISP networks don't crash every other day" says more about the functionality of current multi-homing practices than it does about the stability of the underlying infrastructure. Joe From owner-multi6@ops.ietf.org Fri Jul 18 12:04:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04530 for ; Fri, 18 Jul 2003 12:04:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dXho-000PdJ-DF for multi6-data@psg.com; Fri, 18 Jul 2003 16:03:36 +0000 Received: from [199.67.7.205] (helo=maunakea.aafes.com) by psg.com with esmtp (Exim 4.14) id 19dXhk-000Pd7-Mq for multi6@ops.ietf.org; Fri, 18 Jul 2003 16:03:32 +0000 Received: (from daemon@localhost) by maunakea.aafes.com (8.12.9/8.12.9) id h6IG3U89085049; Fri, 18 Jul 2003 11:03:30 -0500 (CDT) Received: from hqmailbh02.aafes.com(192.168.32.54) via SMTP by maunakea.aafes.com, id smtpdimkhJ5; Fri Jul 18 11:03:23 2003 Received: from HQMAILHA.aafes.com ([192.168.32.21]) by hqmailbh02.aafes.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Jul 2003 11:03:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Minutes / Notes Date: Fri, 18 Jul 2003 11:03:23 -0500 Message-ID: Thread-Topic: Minutes / Notes Thread-Index: AcNNB4v6g8nLPiDzTlG4w98zd5FD9gAPLzKQ From: "Grovesteen, Harold" To: "Brian E Carpenter" , "Tony Li" Cc: X-OriginalArrivalTime: 18 Jul 2003 16:03:23.0647 (UTC) FILETIME=[1D9E50F0:01C34D46] X-Spam-Status: No, hits=-12.8 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Please understand that there is a middle ground between EDI financial = based transactions and checking out a recreational web site. = Enterprises which depend upon user's browsing to generate revenue fit in = this middle ground. It may be casual browsing on the part of the = customer, but there is nothing casual about the enterprise's approach to = reliability to maximize that revenue stream. When millions of dollars = or yen or pounds are at risk, even short disruptions and any broken = connections with those casual users represent lost revenue. I had wanted to stay out of this discussion, but I had not anticipated = the results of my simple affirmation that TCP connection survival is a = good thing and I representing an Enterprise am glad this is still a = "should" and "on the table." I do not even have any issue that some = solutions provide this and others do not. I can select a solution that = does and support my organization as needed--provided it is not = incompatible with the other solutions. Harold Grovesteen -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Friday, July 18, 2003 3:25 AM To: Tony Li Cc: multi6@ops.ietf.org Subject: Re: Minutes / Notes Tony, Yes, but you can't use the same argument for casual web browsing. BTW, this is why commercial message queueing systems exist; they can bridge reliable transactions over significant disconnects. Brian Tony Li wrote: >=20 > Brian, >=20 > If we do not fix this, then we can just close up shop and go home, > because the business world is NOT going to accept a solution that > doesn't fulfill this. They would rather use IPv4 and PI addresses. >=20 > Tony >=20 > | -----Original Message----- > | From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > | Sent: Friday, July 18, 2003 12:58 AM > | To: multi6@ops.ietf.org > | Subject: Re: Minutes / Notes > | > | > | Well, this is one of the many "shoulds" in our agreed list > | of goals. Whether we can achieve this "should" simultaneously > | with enough of the others is very much an open question > | in my mind, and it's one of the reasons why we may end up > | with more than one solution. In some scenarios, this may > | be a dominant goal; in other scenarios, it may be unimportant. > | > | Brian > | > | "Grovesteen, Harold" wrote: > | > > | > YES! > | > > | > -----Original Message----- > | > From: Tony Li [mailto:Tony.Li@procket.com] > | > Sent: Thursday, July 17, 2003 12:38 PM > | > To: J. Noel Chiappa; multi6@ops.ietf.org > | > Subject: RE: Fwd: Minutes / Notes > | > > | > Noel, > | > > | > | This is only important if you want TCP connections to be > | > | able to survive > | > | having an incoming link fail (i.e. the address on the > | > | local end becomes > | > | unreachable to the rest of the network). This may not be > | > | an important goal > | > | (e.g. the typical web site wouldn't care). > | > > | > I believe that the WG has come to rough consensus that this is, > | > in fact, an important goal for us to solve. There are > | > numerous practical applications that drive this. More = generally, > | > we (IETF, vendors) are being asked to make the Internet safe > | > for "mission critical" applications and having broken TCP > | > connections is simply unacceptable. Many applications today > | > are being outsourced: backups, storage, business applications, > | > interactions within an 'extra-net', etc. > | > > | > Tony From owner-multi6@ops.ietf.org Fri Jul 18 13:26:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05974 for ; Fri, 18 Jul 2003 13:26:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dYyN-0003Wh-DI for multi6-data@psg.com; Fri, 18 Jul 2003 17:24:47 +0000 Received: from [65.174.124.36] (helo=dmz1.procket.com) by psg.com with esmtp (Exim 4.14) id 19dYyK-0003U3-LY for multi6@ops.ietf.org; Fri, 18 Jul 2003 17:24:44 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id EBC1823C55; Fri, 18 Jul 2003 10:29:54 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6IHO8YB023237; Fri, 18 Jul 2003 10:24:14 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: Minutes / Notes Date: Fri, 18 Jul 2003 10:24:08 -0700 Message-ID: Thread-Topic: Minutes / Notes Thread-Index: AcNNB4v6g8nLPiDzTlG4w98zd5FD9gAPLzKQAAM4y6A= From: "Tony Li" To: "Grovesteen, Harold" , "Brian E Carpenter" Cc: X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Harold, The problem is that we get to pick one. We're making a fundamental change to the way the Internet works here. There can't be two different architectures... Tony | -----Original Message----- | From: Grovesteen, Harold [mailto:Grovesteen@aafes.com]=20 | Sent: Friday, July 18, 2003 9:03 AM | To: Brian E Carpenter; Tony Li | Cc: multi6@ops.ietf.org | Subject: RE: Minutes / Notes | =20 | =20 | Please understand that there is a middle ground between=20 | EDI financial based transactions and checking out a=20 | recreational web site. Enterprises which depend upon=20 | user's browsing to generate revenue fit in this middle=20 | ground. It may be casual browsing on the part of the=20 | customer, but there is nothing casual about the=20 | enterprise's approach to reliability to maximize that=20 | revenue stream. When millions of dollars or yen or pounds=20 | are at risk, even short disruptions and any broken=20 | connections with those casual users represent lost revenue. | =20 | I had wanted to stay out of this discussion, but I had not=20 | anticipated the results of my simple affirmation that TCP=20 | connection survival is a good thing and I representing an=20 | Enterprise am glad this is still a "should" and "on the=20 | table." I do not even have any issue that some solutions=20 | provide this and others do not. I can select a solution=20 | that does and support my organization as needed--provided=20 | it is not incompatible with the other solutions. | =20 | Harold Grovesteen | =20 | -----Original Message----- | From: Brian E Carpenter [mailto:brian@hursley.ibm.com] | Sent: Friday, July 18, 2003 3:25 AM | To: Tony Li | Cc: multi6@ops.ietf.org | Subject: Re: Minutes / Notes | =20 | =20 | Tony, | =20 | Yes, but you can't use the same argument for casual web browsing. | =20 | BTW, this is why commercial message queueing systems exist; they | can bridge reliable transactions over significant disconnects. | =20 | Brian | =20 | Tony Li wrote: | >=20 | > Brian, | >=20 | > If we do not fix this, then we can just close up shop=20 | and go home, | > because the business world is NOT going to accept a solution that | > doesn't fulfill this. They would rather use IPv4 and PI=20 | addresses. | >=20 | > Tony | >=20 | > | -----Original Message----- | > | From: Brian E Carpenter [mailto:brian@hursley.ibm.com] | > | Sent: Friday, July 18, 2003 12:58 AM | > | To: multi6@ops.ietf.org | > | Subject: Re: Minutes / Notes | > | | > | | > | Well, this is one of the many "shoulds" in our agreed list | > | of goals. Whether we can achieve this "should"=20 | simultaneously | > | with enough of the others is very much an open question | > | in my mind, and it's one of the reasons why we may end up | > | with more than one solution. In some scenarios, this may | > | be a dominant goal; in other scenarios, it may be=20 | unimportant. | > | | > | Brian | > | | > | "Grovesteen, Harold" wrote: | > | > | > | > YES! | > | > | > | > -----Original Message----- | > | > From: Tony Li [mailto:Tony.Li@procket.com] | > | > Sent: Thursday, July 17, 2003 12:38 PM | > | > To: J. Noel Chiappa; multi6@ops.ietf.org | > | > Subject: RE: Fwd: Minutes / Notes | > | > | > | > Noel, | > | > | > | > | This is only important if you want TCP=20 | connections to be | > | > | able to survive | > | > | having an incoming link fail (i.e. the address on the | > | > | local end becomes | > | > | unreachable to the rest of the network).=20 | This may not be | > | > | an important goal | > | > | (e.g. the typical web site wouldn't care). | > | > | > | > I believe that the WG has come to rough consensus=20 | that this is, | > | > in fact, an important goal for us to solve. There are | > | > numerous practical applications that drive this. =20 | More generally, | > | > we (IETF, vendors) are being asked to make the=20 | Internet safe | > | > for "mission critical" applications and having broken TCP | > | > connections is simply unacceptable. Many=20 | applications today | > | > are being outsourced: backups, storage, business=20 | applications, | > | > interactions within an 'extra-net', etc. | > | > | > | > Tony | =20 | =20 From owner-multi6@ops.ietf.org Sat Jul 19 11:29:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16793 for ; Sat, 19 Jul 2003 11:29:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dtbG-000JK8-H4 for multi6-data@psg.com; Sat, 19 Jul 2003 15:26:18 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19dtbC-000JJZ-Eh for multi6@ops.ietf.org; Sat, 19 Jul 2003 15:26:14 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6JFQqxS095914; Sat, 19 Jul 2003 17:26:52 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 19 Jul 2003 17:26:13 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Tony Li" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <55467A3E-B9FD-11D7-8554-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-22.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, jul 18, 2003, at 19:24 Europe/Amsterdam, Tony Li wrote: > The problem is that we get to pick one. We're making a fundamental > change to the way the Internet works here. There can't be two > different architectures... Now obviously if we're going to substantially change the way the internet works to accomodate multihoming, it is inconceivable that we leave out maintaining TCP connections through rehoming events. On the other hand, if we can do multihoming _without_ substantial changes but this means breaking TCP sessions whenever a rehoming event occurs, that _could_ be a legitimate tradeoff. But we haven't reached the point where we can make an informed decision on this yet. But my personal opinion on the matter is that "substantial change" is a red herring. The real question is how hard it is to implement a solution. The substantialness or fundamentalness of the change has little bearing on the implementation difficulty. The adoption of a round earth vs flat earth view is very fundamental but it doesn't change the way you navigate a sailboat through the Mediterranean Sea very much. Iljitsch From owner-multi6@ops.ietf.org Sat Jul 19 12:49:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17755 for ; Sat, 19 Jul 2003 12:49:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19duse-000Opb-Q8 for multi6-data@psg.com; Sat, 19 Jul 2003 16:48:20 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.14) id 19dusa-000OpK-4g for multi6@ops.ietf.org; Sat, 19 Jul 2003 16:48:16 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h6JGmEtU024949; Sat, 19 Jul 2003 12:48:14 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h6JGmEOW024946; Sat, 19 Jul 2003 12:48:14 -0400 Date: Sat, 19 Jul 2003 12:48:14 -0400 From: "J. Noel Chiappa" Message-Id: <200307191648.h6JGmEOW024946@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: Fwd: Minutes / Notes Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Tony Li" >> This is only important if you want TCP connections to be able to >> survive having an incoming link fail .. This may not be an important >> goal > I believe that the WG has come to rough consensus that this is, in > fact, an important goal for us to solve. *It is architecturally crucial that the WG resolve this point.* If you don't need this capability, then the simplest# architectural change you really need to do widespread multi-homing is multiple addresses. (As I have pointed out before, separation of location and identity is not really crucial to do most multi-homing things.) However, if you want connections to a multi-homed entity to be able to withstand loss of connectivity to one of the addresses, then you more or less have to have separation of location and identity. Saying "oh we don't have to separate location and identity - we'll just use a set of addresses, the way SCTP does, or a distinguished address, the way MobileIPv6 does" misses the point: architecturally, even in those cases you *have* separated location and identity - it's just that the "identity" and "location" names are drawn from the same namespace. All the architectural/engineering challenges - such as protecting the binding between the two against intruders, finding the mappings back and forth, handling error recovery, etc, etc, etc are basically the same, whether or not the two namespaces (used for identity and location) are the same or not. Yes, there may be engineering/architectural advantages to having two separate namespaces (with or without identical syntax, an intermediate point) - but that is a *separate* question. There is also the issue of whether or not you want to carry both the location and identity in all packets. You more or less have to have the location, otherwise the packet can't get there. Whether or not you carry the identity as well is an architectural/engineering question. There are also engineering questions having to do with TCP (because of the TCP checksum), and whether or not interoperation with unmodified TCP's is a goal. The latter can be done, but you're probably going to have to do it with something that uses MobileIPv6 mechanisms. I'll stop there for now... Noel #: I said "simplest because there are some other wild ways of doing widespread multi-homing that involve substantial changes to the routing architecture. From owner-multi6@ops.ietf.org Sat Jul 19 13:15:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18186 for ; Sat, 19 Jul 2003 13:15:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dvJ1-0000r6-0l for multi6-data@psg.com; Sat, 19 Jul 2003 17:15:35 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.14) id 19dvIx-0000p3-Nu for multi6@ops.ietf.org; Sat, 19 Jul 2003 17:15:31 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h6JHFUtU025079; Sat, 19 Jul 2003 13:15:30 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h6JHFTd2025078; Sat, 19 Jul 2003 13:15:29 -0400 Date: Sat, 19 Jul 2003 13:15:29 -0400 From: "J. Noel Chiappa" Message-Id: <200307191715.h6JHFTd2025078@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Fwd: Minutes / Notes Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Brian E Carpenter > this is one of the many "shoulds" in our agreed list of goals. Whether > we can achieve this "should" simultaneously with enough of the others > is very much an open question .. it's one of the reasons why we may end > up with more than one solution. In some scenarios, this may be a > dominant goal; in other scenarios, it may be unimportant. I don't think it's realistic to propose the addition of two separate mechanisms to do multi-homing, with slightly different capability sets - one able to keep conections open, and one not (I assume that this latter is done by picking one of N addresses, with no capability to change it). Look, for a multi-homing mechanism to really be really useful, it has to be basically ubiquitously deployed; i.e. if you're multi-homed for reliability, you want *all* your correspondents to be able to get to you when one of your links is offline, not just the limited` subset that implement multi-homing type 17. Once you have the most capable multi-homing mechanism ubiquitously deployed, as far as I can see there is almost no use at all for the less capable versions. There simply isn't that much difference in the operational overhead to make it worth having a second mechanism available, one that's less capable as well. E.g. suppose you go with something that looks like MobileIPv6, where you have location/identity overload in the initial case (you pick one of N addresses, and use that when you open the connection), and then use an additional routing header to keep an existing connection open when the primary link it was using fails. So? The initial case is as efficient as the less-capable version, and if the "link has failed, connection continues" mode of the more-capable version is less efficient, so what? It does something the other can't do. Or suppose you go with 8+8, or a solution where the identity is not carried in every packet. If you want to change the location, there are a couple of packets of negotiation to change the binding and then you're done. Basically all packets are as efficient as the less-capable case. If you go with 16+16, then all the packets have to have an additional header, it's true. But in this design, all connections have to run in this mode all the time, or they lose the capability to survive a link failure. If you have two separate multi-homing mechanisms, then the cost, in system complexity, implementation size, amount of protocol specification work needed, etc, etc just seems to me out of all proportion to the benefit. Talk about second-system disease! Pick one. Noel From owner-multi6@ops.ietf.org Sat Jul 19 14:18:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19195 for ; Sat, 19 Jul 2003 14:18:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dwGW-0005MT-5w for multi6-data@psg.com; Sat, 19 Jul 2003 18:17:04 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19dwGS-0005Lz-WC for multi6@ops.ietf.org; Sat, 19 Jul 2003 18:17:01 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6JIHbxS097677; Sat, 19 Jul 2003 20:17:37 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 19 Jul 2003 20:16:59 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "J. Noel Chiappa" From: Iljitsch van Beijnum In-Reply-To: <200307191715.h6JHFTd2025078@ginger.lcs.mit.edu> Message-Id: <3009AE84-BA15-11D7-8554-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-22.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zaterdag, jul 19, 2003, at 19:15 Europe/Amsterdam, J. Noel Chiappa wrote: > I don't think it's realistic to propose the addition of two separate > mechanisms to do multi-homing, with slightly different capability sets > - one > able to keep conections open, and one not (I assume that this latter > is done > by picking one of N addresses, with no capability to change it). I agree that having two or more mechanisms is undesirable in the long run. On the other hand, solving the source address / ingress filtering issue (which we almost certainly need to do for loc/id anyway) would make it possible to achieve many multihoming benefits by only slightly modifiying applications, i.e., let them cycle through all possible addresses. This is of course not nearly as good as a full solution, but it is much better than what we have now. I'm not a big fan of bringing mobility in the picture, though. I haven't seen any figures on the implementation status of MIPv6 in our collective favorite OSes, but it hardly seems omnipresent. When also considering the complexity of MIPv6 and the fact that MIP assumptions fail badly for multihoming I don't see much value in a MIP approach to multihoming. (If I could I would even like to go further by scrapping MIPv6 wholesale and starting fresh with loc/id for both multihoming and mobility.) From owner-multi6@ops.ietf.org Sat Jul 19 16:08:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21801 for ; Sat, 19 Jul 2003 16:08:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dxzO-000DmK-GB for multi6-data@psg.com; Sat, 19 Jul 2003 20:07:30 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19dxzL-000DlE-6F for multi6@ops.ietf.org; Sat, 19 Jul 2003 20:07:27 +0000 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 19 Jul 2003 13:06:56 -0700 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 19 Jul 2003 13:06:56 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 19 Jul 2003 13:06:55 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 19 Jul 2003 13:06:56 -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.0); Sat, 19 Jul 2003 13:06:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: Fwd: Minutes / Notes Date: Sat, 19 Jul 2003 13:06:57 -0700 Message-ID: Thread-Topic: Fwd: Minutes / Notes Thread-Index: AcNOGgO8IRmdJtegRWGy+9+Lqe25mQAFDPhL From: "Christian Huitema" To: "J. Noel Chiappa" , Cc: X-OriginalArrivalTime: 19 Jul 2003 20:06:58.0522 (UTC) FILETIME=[4F2D03A0:01C34E31] X-Spam-Status: No, hits=-3.2 required=5.0 tests=QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > If you have two separate multi-homing mechanisms, then the cost, in = system > complexity, implementation size, amount of protocol specification work > needed, etc, etc just seems to me out of all proportion to the = benefit. Talk > about second-system disease! Pick one. Frankly, I am not sure about the "pick one". It supposes that we know = exactly what we want to design, and that we can commit to one right now. = Yet, there are very different trade-offs. For example, a fundamental = design choice) is the layer at which identifiers are maintain. Is it = IP, transport or session? The 8+8 and 16+16 designs assume that the = answer is IP; the SCTP design provides a transport based solution that = could in fact easily be retrofitted in a TCP+; many toolkits based on = HTTP or RPC provide a form of session management. It is very unclear to = me that IP would in fact be the right layer for the job. =20 Another quite important design choice is the scope of the identifier. IP = addresses have a well defined scope: they identify a way to send data to = a specific interface in a system. They can be understoud as a contract = between a transmission provider, the IP network, and the host. The scope = of an identifier system, by definition, has to be wider. Yet, we don't = really know how wide. Is it a host? A host is in fact a pretty loose = concept. Consider clusters on one hand, multi-user systems on the other. = Would you have an identifier per node in the cluster, or one per user in = a multi-user system? What about process mobility? If you are running a = distributed application, do you identifiy the application, an instance = of it on a node, or the node that supports this instance? =20 Yet another design choice is the life-time of the identifier. There are = periodic proposals of an identifier baked in a device, e.g. a unique ID = for a 3G phone. But there are also identifiers based on sessions, e.g. = web cookies. And there are very different privacy and reliability = implications between the two variations. =20 I heard many say during the multi6 debate that applications cannot = possibly handle multiple addresses well. To disprove that, I suggest you = take a look at the variations of "swarmcast" implemented by P2P systems = such as Kazaa or E-Donkey. These systems are about exchanging files, so = they have their own identification system -- file names. The naming = system can resolve file names to multiple locations of a file. The = transfer system then asks slices of the file from a set of more or less = randomly chosen locations. It automatically adjust to topology by = asking more from those locations that serve faster. And it automatically = compensate connection losses by just repeating the slice request, or a = fraction of it, to some other nodes. Such a system would handle = multi-addressing beautifully. =20 But my real point when bringing up the P2P example is that innovation = happens. Swarmcast is just an example. Real-time multi-media systems are = investigating something similar using layered encoded stripes instead of = slices. Office automation systems use transaction processing. The list = goes on. What we are observing is a distributed innovation process = arbitraged by the market place. I trust that much more than a = identifier/location split designed by committee. =20 -- Christian Huitema From owner-multi6@ops.ietf.org Sat Jul 19 17:39:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23335 for ; Sat, 19 Jul 2003 17:39:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dzP8-000Kr1-D8 for multi6-data@psg.com; Sat, 19 Jul 2003 21:38:10 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.14) id 19dzP6-000KpH-3a for multi6@ops.ietf.org; Sat, 19 Jul 2003 21:38:08 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 6637E34443; Sat, 19 Jul 2003 14:55:03 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6JLbWYB005555; Sat, 19 Jul 2003 14:37:32 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: Minutes / Notes MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 19 Jul 2003 14:37:32 -0700 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: Minutes / Notes Thread-Index: AcNOGgO8IRmdJtegRWGy+9+Lqe25mQAFDPhLAAPmlIA= From: "Tony Li" To: "Christian Huitema" , "J. Noel Chiappa" , Cc: X-Spam-Status: No, hits=-1.6 required=5.0 tests=BAYES_30 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable | Frankly, I am not sure about the "pick one". It supposes=20 | that we know exactly what we want to design, and that we=20 | can commit to one right now.=20 That's fine by me. Let's bring back TUBA then. ;-) ;-) ;-) Tony From owner-multi6@ops.ietf.org Sun Jul 20 04:05:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14213 for ; Sun, 20 Jul 2003 04:05:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19e9A9-000Mpr-Ab for multi6-data@psg.com; Sun, 20 Jul 2003 08:03:21 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19e9A6-000MpJ-M9 for multi6@ops.ietf.org; Sun, 20 Jul 2003 08:03:18 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id E367E23; Sun, 20 Jul 2003 11:12:25 +0300 (EEST) Message-ID: <3F1A4CAB.8010005@nomadiclab.com> Date: Sun, 20 Jul 2003 11:02:51 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Cc: Christian Huitema Subject: Scope of an Identifier? (Re: Fwd: Minutes / Notes) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-33.8 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Firstly, IMHO it is very good that the WG seems to be converging to the notion that we basically have to make the id/loc separation. Now, if we do make that, Christian is asking a couple of very good questions. I also think that we already know some possible good answers to these questions. It is then another matter whether we want to go with the better answers or be happy with some lesser ones. Christian Huitema wrote: > Another quite important design choice is the scope of the identifier. > ... The scope of an identifier system, by definition, has to be > wider [than the scope of an IP address]. Yet, we don't really know > how wide. Is it a host? A host is in fact a pretty loose concept. > Consider clusters on one hand, multi-user systems on the other. Would > you have an identifier per node in the cluster, or one per user in a > multi-user system? What about process mobility? If you are running a > distributed application, do you identifiy the application, an > instance of it on a node, or the node that supports this instance? If we can design our architecture and solution in such a way that is remains basically an *operational* choice to decide the scope of an identifier, then I think we have reached a good solution. This seems to reduce to a situation where one can assign an identifier to any process group. Then it remains a matter internal to that process group and the underlying hosts to arrange clustering, process group migration, etc. In practise, we can start by saying that an identifier identifies a host, but engineer the solution in such a way that the connection between the identifier and the host is a relatively loose one, allowing more flexibility in the future. > Yet another design choice is the life-time of the identifier. There > are periodic proposals of an identifier baked in a device, e.g. a > unique ID for a 3G phone. But there are also identifiers based on > sessions, e.g. web cookies. And there are very different privacy and > reliability implications between the two variations. IMHO, we need identifiers that have different lifetime and different privacy properties. We want to have identifiers that are short lived and anonymous. We need identifiers that have a longer lifetime, act as pseudonyms, and may be assocated with some local credentials. Finally, we probably also need long lived identifiers, associated with credentials with more or less global scope. The identifier name space should accomodate all these. Furthermore, it MUST NOT make any syntactical distinction between these three of these. That is, just by looking at an identifier it MUST BE impossible to tell its lifetime and privacy status. (Why? Think about collecting and correlating identifiers vs. privacy). --Pekka Nikander From owner-multi6@ops.ietf.org Sun Jul 20 08:40:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17796 for ; Sun, 20 Jul 2003 08:40:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eDR9-0007D1-IC for multi6-data@psg.com; Sun, 20 Jul 2003 12:37:11 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19eDR5-0007Co-W1 for multi6@ops.ietf.org; Sun, 20 Jul 2003 12:37:08 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6KCbjxS009248; Sun, 20 Jul 2003 14:37:45 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 20 Jul 2003 14:37:09 +0200 Subject: Re: Source address selection in IPv6 multihomed multi-addressed sites Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Cedric de Launois From: Iljitsch van Beijnum In-Reply-To: <3F156970.6050404@info.ucl.ac.be> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-14.4 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, jul 16, 2003, at 17:04 Europe/Amsterdam, Cedric de Launois wrote: > These are my random thoughts about source address > selection in IPv6 multihomed multi-addressed sites. > > I believe this problem needs to be resolved to get > a complete IPv6 multi-addressing multihoming solution. [...] > Any comment/suggestion/correction ? I think your remarks on the mechanisms you mention are (nearly) all good points. However, I think we need to take a step back and consider the more fundamental problem. The fundamental problem is that we really need to avoid source address spoofing, as this makes certain kinds of abuse nearly impossible to stop. (I.e., people can launch DoS attacks and the attacked systems can't see where the attack came from and they can't filter out the abusive traffic.) So it is assumed that ISPs will filter their customer's traffic and only let packets with valid source addresses through. This gives us a range of options: 1. do nothing (what we do today) -> traffic will regularly not make it through -> a lot of unhappiness 2. ask ISP to let traffic through -> ISP may say no -> much unhappiness or upstream ISP filters -> also unhappiness 3. figure out the right source address (sort of happens today automatically sometimes) -> traffic will get through, but if the destination is rerouted over the other link the session breaks -> still considerable unhappiness 4. do source address dependent routing -> easy when only one box does this, harder in sites where there is internal routing, still problems with routing changes If we get to change source addresses for existing sessions, we still need to do 3 or 4 but then we get to survive routing changes without breaking sessions, or we can rewrite the source address on egress and we're done. This has the advantage of being very once it is implemented in all border routers, but I'm afraid of problems in getting to that situation. Also, source address dependent routing gives the host more control over the path the traffic takes, which is good for performance and redundancy. From owner-multi6@ops.ietf.org Sun Jul 20 09:11:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18355 for ; Sun, 20 Jul 2003 09:11:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eDwl-0008Yf-PA for multi6-data@psg.com; Sun, 20 Jul 2003 13:09:51 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19eDwi-0008YT-Jy for multi6@ops.ietf.org; Sun, 20 Jul 2003 13:09:49 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6KDAKxS009589; Sun, 20 Jul 2003 15:10:20 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 20 Jul 2003 15:09:44 +0200 Subject: Re: Source address selection in IPv6 multihomed multi-addressed sites Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Iljitsch van Beijnum In-Reply-To: <200307180556.OAA14096@necom830.hpcl.titech.ac.jp> Message-Id: <6E592DA4-BAB3-11D7-8554-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-24.1 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, jul 18, 2003, at 07:57 Europe/Amsterdam, Masataka Ohta wrote: > However, to enable source address filtering to discard packets with > source addresses not belonging to an ISP, it is useful to enable a > host, not some intelligent intermediate router, select a source > address compatible with an outgoing ISP. For that purpose, intra > domain routing protocols or something like that should maintain > routing table entries with not only preference values of an external > routes, but also proper prefixes to be selected for source > addresses, > if the entries are chosen by a host. > It should be noted that it is already doable with the current OSPF > spec. Hm, how would that work? In BGP you could see the next hop AS number and map this to a source address, but in OSPF there is no obvious way to do this. (Although I'm sure a non-obvious way can be created.) However, I certainly wouldn't want hosts to interact with OSPF as this is a somewhat fragile protocol. In RIP you can simply ignore what hosts have to say and in BGP you can filter it, but in OSPF as-is you can only hope the host don't send any information that screws up the routing table. And then there is still the problem of how useful this information is. Even today with BGP is is fairly common that BGP selects a very bad route because A and F can either communicate through B and C or through D and E. As far as BGP is concernet the paths are equally preferable: A - B - C - F or A - D - E - F. What BGP doesn't know is that the interconnect between B and C is 500 km away while the interconnect between D and E is on another continent. Obviously this problem is only going to get worse as the routing table becomes smaller. That's why I think that there will always be upward pressure for the routing table size. From owner-multi6@ops.ietf.org Sun Jul 20 09:12:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18389 for ; Sun, 20 Jul 2003 09:12:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eDyb-0008eY-R0 for multi6-data@psg.com; Sun, 20 Jul 2003 13:11:45 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19eDyZ-0008do-4M for multi6@ops.ietf.org; Sun, 20 Jul 2003 13:11:43 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6KDCIxS009615; Sun, 20 Jul 2003 15:12:18 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 20 Jul 2003 15:11:41 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Iljitsch van Beijnum In-Reply-To: <200307180640.PAA14351@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, jul 18, 2003, at 08:41 Europe/Amsterdam, Masataka Ohta wrote: >> I have a few technical (not editorial) comments on some points in the >> minutes, >> which are therefore of general interest... > A problem is that the minutes lacks discussioin on so many errors of > Iljitsch's proposal that yo are repeating my points at the meeting Well, let's hear it then. What are those errors? From owner-multi6@ops.ietf.org Sun Jul 20 13:47:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23213 for ; Sun, 20 Jul 2003 13:47:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eIDe-000IZE-2j for multi6-data@psg.com; Sun, 20 Jul 2003 17:43:34 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19eIDb-000IYn-CF for multi6@ops.ietf.org; Sun, 20 Jul 2003 17:43:31 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 9FFE643201; Sun, 20 Jul 2003 19:43:14 +0200 (CEST) Received: from lolo (vpn-252-72.uc3m.es [163.117.252.72]) by smtp02.uc3m.es (Postfix) with SMTP id BF1D599FB6; Sun, 20 Jul 2003 19:43:10 +0200 (CEST) From: "marcelo bagnulo" To: "Iljitsch van Beijnum" , "J. Noel Chiappa" Cc: Subject: RE: Minutes / Notes Date: Sun, 20 Jul 2003 17:41:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3009AE84-BA15-11D7-8554-00039388672E@muada.com> X-Spam-Status: No, hits=-17.9 required=5.0 tests=BAYES_10,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Iljitsch, > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Iljitsch van Beijnum > Enviado el: sabado, 19 de julio de 2003 20:17 > Para: J. Noel Chiappa > CC: multi6@ops.ietf.org > Asunto: Re: Minutes / Notes > > > On zaterdag, jul 19, 2003, at 19:15 Europe/Amsterdam, J. Noel Chiappa > wrote: > > > I don't think it's realistic to propose the addition of two separate > > mechanisms to do multi-homing, with slightly different capability sets > > - one > > able to keep conections open, and one not (I assume that this latter > > is done > > by picking one of N addresses, with no capability to change it). > > I agree that having two or more mechanisms is undesirable in the long > run. > > On the other hand, solving the source address / ingress filtering issue > (which we almost certainly need to do for loc/id anyway) would make it > possible to achieve many multihoming benefits by only slightly > modifiying applications, i.e., let them cycle through all possible > addresses. This is of course not nearly as good as a full solution, but > it is much better than what we have now. > > I'm not a big fan of bringing mobility in the picture, though. I > haven't seen any figures on the implementation status of MIPv6 in our > collective favorite OSes, but it hardly seems omnipresent. When also > considering the complexity of MIPv6 and the fact that MIP assumptions > fail badly for multihoming I don't see much value in a MIP approach to > multihoming. > > (If I could I would even like to go further by scrapping MIPv6 > wholesale and starting fresh with loc/id for both multihoming and > mobility.) > > I guess i agree with most of your comments, however i think that you are missing an important issue which is timing. MIPv6 is already an RFC and it is being deployed now, so soon CN functionality can be on most implementations. So we could do a whole new stuff (and i think we need to do it) but meanwhile we should benefit from this mipv6 capabilities which will be available on nodes. Regards, marcelo From owner-multi6@ops.ietf.org Sun Jul 20 13:47:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23230 for ; Sun, 20 Jul 2003 13:47:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eIDo-000IZV-Ew for multi6-data@psg.com; Sun, 20 Jul 2003 17:43:44 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19eIDl-000IYl-GV for multi6@ops.ietf.org; Sun, 20 Jul 2003 17:43:41 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 93D99431F6; Sun, 20 Jul 2003 19:43:10 +0200 (CEST) Received: from lolo (vpn-252-72.uc3m.es [163.117.252.72]) by smtp02.uc3m.es (Postfix) with SMTP id 9FDE799FBC; Sun, 20 Jul 2003 19:43:08 +0200 (CEST) From: "marcelo bagnulo" To: "J. Noel Chiappa" , Subject: RE: Fwd: Minutes / Notes Date: Sun, 20 Jul 2003 17:41:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <200307191715.h6JHFTd2025078@ginger.lcs.mit.edu> X-Spam-Status: No, hits=-15.2 required=5.0 tests=BAYES_20,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi Noel, > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de J. Noel Chiappa > Enviado el: sábado, 19 de julio de 2003 19:15 > Para: multi6@ops.ietf.org > CC: jnc@ginger.lcs.mit.edu > Asunto: Re: Fwd: Minutes / Notes > > > > From: Brian E Carpenter > > > this is one of the many "shoulds" in our agreed list of > goals. Whether > > we can achieve this "should" simultaneously with enough of > the others > > is very much an open question .. it's one of the reasons > why we may end > > up with more than one solution. In some scenarios, this may be a > > dominant goal; in other scenarios, it may be unimportant. > > I don't think it's realistic to propose the addition of two separate > mechanisms to do multi-homing, with slightly different capability > sets - one > able to keep conections open, and one not (I assume that this > latter is done > by picking one of N addresses, with no capability to change it). > > Look, for a multi-homing mechanism to really be really useful, it > has to be > basically ubiquitously deployed; i.e. if you're multi-homed for > reliability, > you want *all* your correspondents to be able to get to you when > one of your > links is offline, not just the limited` subset that implement multi-homing > type 17. > I think that what Brian means is that different sites can internally adopt different solutions, which in turn will provide them different benefits. Clearly, a solution should not depend on special features on nodes outside the multi-homed site. (However, it is posible to think that given solutions would benefit from optimizations on nodes outside the multi-homed sites) Regards, marcelo > Once you have the most capable multi-homing mechanism > ubiquitously deployed, > as far as I can see there is almost no use at all for the less capable > versions. There simply isn't that much difference in the > operational overhead > to make it worth having a second mechanism available, one that's > less capable > as well. > > > E.g. suppose you go with something that looks like MobileIPv6, > where you have > location/identity overload in the initial case (you pick one of N > addresses, > and use that when you open the connection), and then use an additional > routing header to keep an existing connection open when the > primary link it > was using fails. So? The initial case is as efficient as the less-capable > version, and if the "link has failed, connection continues" mode of the > more-capable version is less efficient, so what? It does > something the other > can't do. > > Or suppose you go with 8+8, or a solution where the identity is > not carried > in every packet. If you want to change the location, there are a couple of > packets of negotiation to change the binding and then you're > done. Basically > all packets are as efficient as the less-capable case. > > If you go with 16+16, then all the packets have to have an > additional header, > it's true. But in this design, all connections have to run in > this mode all > the time, or they lose the capability to survive a link failure. > > > If you have two separate multi-homing mechanisms, then the cost, in system > complexity, implementation size, amount of protocol specification work > needed, etc, etc just seems to me out of all proportion to the > benefit. Talk > about second-system disease! Pick one. > > Noel > From owner-multi6@ops.ietf.org Sun Jul 20 13:47:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23259 for ; Sun, 20 Jul 2003 13:47:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eIDr-000IZk-0b for multi6-data@psg.com; Sun, 20 Jul 2003 17:43:47 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19eIDo-000IYm-Dp for multi6@ops.ietf.org; Sun, 20 Jul 2003 17:43:44 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id AB7E443200; Sun, 20 Jul 2003 19:43:13 +0200 (CEST) Received: from lolo (vpn-252-72.uc3m.es [163.117.252.72]) by smtp02.uc3m.es (Postfix) with SMTP id 8505299FAC; Sun, 20 Jul 2003 19:43:12 +0200 (CEST) From: "marcelo bagnulo" To: "J. Noel Chiappa" , Subject: RE: Fwd: Minutes / Notes Date: Sun, 20 Jul 2003 17:41:59 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <200307191648.h6JGmEOW024946@ginger.lcs.mit.edu> X-Spam-Status: No, hits=-14.3 required=5.0 tests=BAYES_30,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi Noel > > There is also the issue of whether or not you want to carry both > the location > and identity in all packets. You more or less have to have the location, > otherwise the packet can't get there. Whether or not you carry > the identity > as well is an architectural/engineering question. As it was mentioned in the meeting, information contained in packets binding locators to identifiers can not be trusted (unless it is secured with additional tools), so i guess that it is only needed to carry both identifier and locators in packets that convey binding information securely which shouldn´t be in all packets. So, i guess that you need to carry the locator of the destination, since it is needed to forward the packet to the destination. I guess that you don´t need to carry the destination identifier in all packets. For the source endpoint information, i am not sure. I think that carrying the source identifier would make more sense, since it identifies the other endd of the communication. This would also allow to configure filters depending on the source identifier making things like renumbering easier. The first problem that i find with this option is that you cannot send error messages back to the source (since there is no locator of the source) when there is a problem and additional mechanisms are needed to perform reverse mapping in this situation. So (without much analysis) i would say that packets should contain the destination locator and the source identifier, but i am certainly missing many things here. Regards, marcelo > > There are also engineering questions having to do with TCP (because of the > TCP checksum), and whether or not interoperation with unmodified > TCP's is a > goal. The latter can be done, but you're probably going to have > to do it with > something that uses MobileIPv6 mechanisms. > > I'll stop there for now... > > > Noel > > > #: I said "simplest because there are some other wild ways of doing > widespread multi-homing that involve substantial changes to the routing > architecture. > From owner-multi6@ops.ietf.org Sun Jul 20 13:47:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23276 for ; Sun, 20 Jul 2003 13:47:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eIDT-000IZ0-VW for multi6-data@psg.com; Sun, 20 Jul 2003 17:43:23 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19eIDQ-000IYk-QJ for multi6@ops.ietf.org; Sun, 20 Jul 2003 17:43:21 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 78368431BF; Sun, 20 Jul 2003 19:43:10 +0200 (CEST) Received: from lolo (vpn-252-72.uc3m.es [163.117.252.72]) by smtp02.uc3m.es (Postfix) with SMTP id 1913E99FB6; Sun, 20 Jul 2003 19:43:06 +0200 (CEST) From: "marcelo bagnulo" To: "Pekka Savola" , "Brian E Carpenter" Cc: Subject: RE: Fwd: Minutes / Notes Date: Sun, 20 Jul 2003 17:41:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 5 (Lowest) X-MSMail-Priority: Low X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Low X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: X-Spam-Status: No, hits=-14.3 required=5.0 tests=BAYES_30,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, [...] > However, I also think that one must apply some reason here. For example, > if you have have tunnels from two access routers to two ISP's ("site exit > routers approach"), I don't think you have to care about connection > survivability that much. > > ISPs' networks don't crash every other day (if they do, change the ISPs; > we just can't design protocols to work around broken operational > practices: that's going to fail, no matter what). Might happen a couple > of times during the year, at most, but I'm not convinced that's > necessarily a huge problem. Do you think that this is an acceptable solution fo very small sites? I mean, suppose an scenario where very small site multihoming becomes very frequent, so the number of those sites is very high. site Exit router approach requires manual configuration of the tunnels by both ISPs, so do you think that isps will be willing to do this for very small sites? An complementary approach would be to use some sort of tunnel broker so that the site itself could configure its own tunnels, so the isps operators do not have to deal with this, what do you think? Regards, marcelo > > > > -----Original Message----- > > > From: Tony Li [mailto:Tony.Li@procket.com] > > > Sent: Thursday, July 17, 2003 12:38 PM > > > To: J. Noel Chiappa; multi6@ops.ietf.org > > > Subject: RE: Fwd: Minutes / Notes > > > > > > Noel, > > > > > > | This is only important if you want TCP connections to be > > > | able to survive > > > | having an incoming link fail (i.e. the address on the > > > | local end becomes > > > | unreachable to the rest of the network). This may not be > > > | an important goal > > > | (e.g. the typical web site wouldn't care). > > > > > > I believe that the WG has come to rough consensus that this is, > > > in fact, an important goal for us to solve. There are > > > numerous practical applications that drive this. More generally, > > > we (IETF, vendors) are being asked to make the Internet safe > > > for "mission critical" applications and having broken TCP > > > connections is simply unacceptable. Many applications today > > > are being outsourced: backups, storage, business applications, > > > interactions within an 'extra-net', etc. > > > > > > Tony > > > > -- > 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 Jul 20 13:55:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23369 for ; Sun, 20 Jul 2003 13:54:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eINl-000JDX-QE for multi6-data@psg.com; Sun, 20 Jul 2003 17:54:01 +0000 Received: from [192.139.46.78] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.14) id 19eINi-000JDK-EV for multi6@ops.ietf.org; Sun, 20 Jul 2003 17:53:58 +0000 Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h6KHpvW12163 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 20 Jul 2003 13:52:08 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h6KHqQR6021264 for ; Sun, 20 Jul 2003 13:52:29 -0400 To: multi6@ops.ietf.org Subject: Re: Minutes / Notes In-reply-to: Your message of "Sat, 19 Jul 2003 17:26:13 +0200." <55467A3E-B9FD-11D7-8554-00039388672E@muada.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 20 Jul 2003 13:52:26 -0400 Message-ID: <21263.1058723546@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Status: No, hits=-15.2 required=5.0 tests=BAYES_20,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Iljitsch" == Iljitsch van Beijnum writes: Iljitsch> On the other hand, if we can do multihoming _without_ Iljitsch> substantial changes but this means breaking TCP sessions Iljitsch> whenever a rehoming event occurs, that _could_ be a legitimate Iljitsch> tradeoff. My opinion is that there are some additional provisos that will show up that permit people who care to do something to make the session survive. One of those will be SCTP, but there may be other things. As such, the "cost" of that tradeoff may be reduceable to those willing to make minor investments. Iljitsch> change" is a red herring. The real question is how hard it is to Iljitsch> implement a solution. The substantialness or fundamentalness of Iljitsch> the change has little bearing on the implementation Iljitsch> difficulty. The adoption of a round earth vs flat earth view is Iljitsch> very fundamental but it Iljitsch> doesn't change the way you navigate a sailboat through the Iljitsch> Mediterranean Sea very much. I agree. Any change to an end system is substantial. As such, a change is a change is a change. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBPxrW2YqHRg3pndX9AQEDqAP/bdMlVNWH/SvUWMOM2jn/wwZjF/z+NAbP ijGQhaQ21W+O7RA5xZqPVE48muB4fO1SxLd6ABDF4uUVAuZsy1baYXxrionMxojj wUGelzbkhHbdzPQeFt2WEp7sWx4bn+HQmczIsYIWgZGXg1Hx8qp+w3h82Zn8aTcs Twi0C57xK3M= =UmP4 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sun Jul 20 14:12:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23512 for ; Sun, 20 Jul 2003 14:12:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eIe9-000K7Q-L8 for multi6-data@psg.com; Sun, 20 Jul 2003 18:10:57 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19eIe7-000K5O-Bs for multi6@ops.ietf.org; Sun, 20 Jul 2003 18:10:55 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 0BEFB23; Sun, 20 Jul 2003 21:20:03 +0300 (EEST) Message-ID: <3F1ADB13.2010809@nomadiclab.com> Date: Sun, 20 Jul 2003 21:10:27 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo Cc: multi6@ops.ietf.org Subject: Re: Fwd: Minutes / Notes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-35.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: > For the source endpoint information, i am not sure > I think that carrying the source identifier would make more sense, since it > identifies the other endd of the communication. Carrying a source identifier is harmful. For our argument, see Catharina Candolin and Pekka Nikander, "IPv6 Source Addresses Considered Harmful," in Hanne Riis Nielson (ed.), Proceedings of NordSec 2001, Sixth Nordoc Workshop on Secure IT Systems, November 1-2, Lyngby, Denmark, Technical Report IMM-TR-2001-14, pp. 54-68, Technical University of Denmark, November 2001. http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf > This would also allow to > configure filters depending on the source identifier making things like > renumbering easier. The first problem that i find with this option is that > you cannot send error messages back to the source (since there is no locator > of the source) when there is a problem and additional mechanisms are needed > to perform reverse mapping in this situation. Error messages (ICMP, congestion notification) are about the only reason why you should have any kind of source names in the average packets once you make the id/loc separation. In fact, IMHO it would make most sense to *record* the source *path* to the packets, somewhat ala itrace, if the id/loc separation is made. That would allow one to trace back DoS packets. (Note that all of the above discussed *generic* packets. It is a different issue with the very first packet send by a host to another, and in any packets that affect the id->locs binding. --Pekka Nikander From owner-multi6@ops.ietf.org Sun Jul 20 17:21:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27952 for ; Sun, 20 Jul 2003 17:21:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eLZT-0004wh-UK for multi6-data@psg.com; Sun, 20 Jul 2003 21:18:19 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19eLZO-0004wO-SW for multi6@ops.ietf.org; Sun, 20 Jul 2003 21:18:15 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6KLIlxS014725; Sun, 20 Jul 2003 23:18:47 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 20 Jul 2003 23:18:06 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "marcelo bagnulo" From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, jul 20, 2003, at 17:41 Europe/Amsterdam, marcelo bagnulo wrote: > For the source endpoint information, i am not sure. > I think that carrying the source identifier would make more sense, > since it > identifies the other endd of the communication. This would also allow > to > configure filters depending on the source identifier making things like > renumbering easier. The first problem that i find with this option is > that > you cannot send error messages back to the source (since there is no > locator > of the source) when there is a problem and additional mechanisms are > needed > to perform reverse mapping in this situation. Having the source identifier rather than a source locator in packets might be useful. It certainly makes "big" easier to implement. I don't think sending back ICMP messages would be a huge obstacle in practice: a box somewhere in the ISP network can source an aggregate route for the whole identifier space and replace the identifier in the destination address with an appropriate locator. The ingress filtering issue is a bigger issue. But I think this approach may actually strengthen anti-DOS measures rather than weaken them, as we're in the position to mandate mechanisms for tracking and controlling source addresses for the new identifier space from the start. For instance, we could have the mapping between an organization and its identifier address space be cryptographically signed by the registry. Then whenever abuse is suspected (for instance, because of high traffic volumes or complaints) it is possible to send a challenge to the source as indicated by the identifier, who can then either acknowledge that the traffic is theirs (and use a signature to prove this) or deny it so the traffic can be filtered. It should even be possible for the acknowledgement to contain information about allowed traffic types and rates so illegitimate use of network resources by the legitimate holder of an address can be automatically detected and stopped. The challenge/response with signature thing can also be used to automatically adjust ingress filtering at the ISP side. From owner-multi6@ops.ietf.org Sun Jul 20 17:41:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28146 for ; Sun, 20 Jul 2003 17:41:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eLua-0006Aw-3G for multi6-data@psg.com; Sun, 20 Jul 2003 21:40:08 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19eLuM-00067g-WB for multi6@ops.ietf.org; Sun, 20 Jul 2003 21:39:55 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6KLeXxS014955; Sun, 20 Jul 2003 23:40:33 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 20 Jul 2003 23:39:52 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Christian Huitema" From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-25.6 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zaterdag, jul 19, 2003, at 22:06 Europe/Amsterdam, Christian Huitema wrote: >> If you have two separate multi-homing mechanisms, then the cost, in >> system >> complexity, implementation size, amount of protocol specification work >> needed, etc, etc just seems to me out of all proportion to the >> benefit. Talk >> about second-system disease! Pick one. > > Frankly, I am not sure about the "pick one". It supposes that we know > exactly what we want to design, and that we can commit to one right > now. Yet, there are very different trade-offs. For example, a > fundamental design choice) is the layer at which identifiers are > maintain. Is it IP, transport or session? The 8+8 and 16+16 designs > assume that the answer is IP; the SCTP design provides a transport > based solution that could in fact easily be retrofitted in a TCP+; > many toolkits based on HTTP or RPC provide a form of session > management. It is very unclear to me that IP would in fact be the > right layer for the job. Christian, did you see my message with subject "More random and not so random thoughts" from a few days ago? Here I address these issues. I would very much like your input on my reasoning there. > Another quite important design choice is the scope of the identifier. > IP addresses have a well defined scope: they identify a way to send > data to a specific interface in a system. They can be understoud as a > contract between a transmission provider, the IP network, and the > host. The scope of an identifier system, by definition, has to be > wider. Yes, this is true even today in IPv4: the locator function of the address concerns itself with the interface. At the same time, the identifier function works host-wide: when a packet is received over another interface than the one the packet is addressed to, and often even if this interface is down, the packet processed as the host recognizes it is addressed to it. > Yet, we don't really know how wide. Is it a host? A host is in fact a > pretty loose concept. Consider clusters on one hand, multi-user > systems on the other. Would you have an identifier per node in the > cluster, or one per user in a multi-user system? What about process > mobility? If you are running a distributed application, do you > identifiy the application, an instance of it on a node, or the node > that supports this instance? I don't pretend to have all the answers here (hmmm, does this mean I normally do pretend to have all the answers?) but I have a hard time coming up with a reason why this would matter. Does the nature of that which is identified really change the identifiyng process and whatever else depends on this process? > I heard many say during the multi6 debate that applications cannot > possibly handle multiple addresses well. I'm not sure if you're referring to anything I've said, but if so: that's not what I meant. Well-designed applications could in fact handle this well, in some cases maybe even better than a generic mechanism as the application has better knowledge of what is a good idea for the task it needs to accomplish. But see my list of issues in the message I mentioned earlier for why having the applications do this as a rule is still a bad idea, IMO. And there is of course the fact that an application can't make TCP switch addresses in mid-session. > But my real point when bringing up the P2P example is that innovation > happens. Swarmcast is just an example. Real-time multi-media systems > are investigating something similar using layered encoded stripes > instead of slices. Office automation systems use transaction > processing. The list goes on. What we are observing is a distributed > innovation process arbitraged by the market place. I trust that much > more than a identifier/location split designed by committee. Are you saying multihoming as we know it today, where we try to maintain (amongst others) running TCP sessions across rehoming events, is of no value? From owner-multi6@ops.ietf.org Sun Jul 20 18:05:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28663 for ; Sun, 20 Jul 2003 18:05:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eMIQ-0007n7-Ap for multi6-data@psg.com; Sun, 20 Jul 2003 22:04:46 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.14) id 19eMIN-0007mu-M3 for multi6@ops.ietf.org; Sun, 20 Jul 2003 22:04:43 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h6KM4gtU000909; Sun, 20 Jul 2003 18:04:42 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h6KM4fMi000906; Sun, 20 Jul 2003 18:04:41 -0400 Date: Sun, 20 Jul 2003 18:04:41 -0400 From: "J. Noel Chiappa" Message-Id: <200307202204.h6KM4fMi000906@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Fwd: Minutes / Notes Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-1.6 required=5.0 tests=BAYES_30 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Keith Moore > It is essential that TCP connections be able to survive link failures. > If you don't have this, you basically have to re-implement much of TCP > at a higher layer. (Typically, explicit acks for application data, the > ability to detect a lack of acknowledgment and to retransmit > unacknowledged application data, and to gracefully handle duplicate > transmissions of application data.) Some of this you have to do anyway (e.g. "explicit acks for application data, [and] the ability to detect a lack of acknowledgment") because the application at the far end may consume your data (so you get an ACK from the TCP layer), and then hang. TCP's happy, and if you're depending on TCP to give you an error you'll be waiting forever. But to more broadly discuss your point, surely you have to have some higher- level mechanism to recover from failures anyway, for fairly terminal situations; e.g. if the entity on the fair end crashes, or if the entity on the far end is singly-homed, not multiply-homes, and its link fails. So if you have to have such a mechanism anyway, I don't find the argument you cited to be very conclusive. However, I don't think that settles the general question, of whether the benefit of yet another mechanism (to allow TCP connections from a multi-homed host be able to survive having an incoming link fail) is large enough to be worth the extra complexity. Noel From owner-multi6@ops.ietf.org Sun Jul 20 18:51:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00102 for ; Sun, 20 Jul 2003 18:51:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eN0W-000AQU-2c for multi6-data@psg.com; Sun, 20 Jul 2003 22:50:20 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.14) id 19eN0T-000AQB-9n for multi6@ops.ietf.org; Sun, 20 Jul 2003 22:50:17 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h6KMoFtU001057; Sun, 20 Jul 2003 18:50:15 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h6KMoFmL001056; Sun, 20 Jul 2003 18:50:15 -0400 Date: Sun, 20 Jul 2003 18:50:15 -0400 From: "J. Noel Chiappa" Message-Id: <200307202250.h6KMoFmL001056@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: Fwd: Minutes / Notes Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Christian Huitema" Christian, you've raised two important points. I'm going to reply to this one first, separately. > there are very different trade-offs. For example, a fundamental design > choice) is the layer at which identifiers are maintain. Is it IP, > transport or session? > ... > Another quite important design choice is the scope of the identifier. .. > Is it a host? .. Consider clusters on one hand, multi-user systems on > the other. > ... > Yet another design choice is the life-time of the identifier. .. And > there are very different privacy and reliability implications between > the two variations. > ... > I trust that much more than a identifier/location split designed by > committee. I think you're confusing two separate but related points. Your points (expressed above) relate to the semantics and properties of a potential "identity" name. However, this is a *separate* set of questions from "do you split location and identity". If you do certain functional things, you *are* separating location and identity, whether you admit it or not. For instance, MIPv6 separates location and identity. The namespace they use for the "identity" name happens to be the same namespace as the "location" namespace, but that's an orthagonal issue. Anytime you separate location and identity, that separation brings with it certain inevitable architectural and engineering points - and if you don't believe me, take a look at the length of the MIPv6 spec. You have to secure the binding, handle broken bindings, etc, etc, etc. Similarly, iff you i) handle multi-homing with multiple addresses, and ii) allow any "connection" which identifies the entity at the far end by its address (such as TCP, as currently defined) to survive that address becoming non-working - then you are again separating "location" and "identity", with all the architectural and engineering issues that brings - *even if the namespace you use for the "identity" name happens to be the same namespace as the "location" namespace*, as in MIPv6. It is for that reason that I press people to decide whether or not they really need to support that capability, of having TCP connections survive the failure of one address. Having decided to separate location and identity, then you get to the question of i) whether you use the same namespace for both, and if not ii) what the properties of the second namespace are - the questions you raise above. But don't mistake these questions for the first question - of whether you do the separation. Noel From owner-multi6@ops.ietf.org Sun Jul 20 19:43:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01150 for ; Sun, 20 Jul 2003 19:43:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eNoc-000Dkm-J9 for multi6-data@psg.com; Sun, 20 Jul 2003 23:42:06 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19eNoZ-000Dhs-V2 for multi6@ops.ietf.org; Sun, 20 Jul 2003 23:42:03 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 20 Jul 2003 16:41:33 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 20 Jul 2003 16:41:33 -0700 Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 20 Jul 2003 16:41:33 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 20 Jul 2003 16:41:24 -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); Sun, 20 Jul 2003 16:41:32 -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.0); Sun, 20 Jul 2003 16:41:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: Fwd: Minutes / Notes Date: Sun, 20 Jul 2003 16:41:30 -0700 Message-ID: Thread-Topic: Fwd: Minutes / Notes Thread-Index: AcNPExXXncOVYR6hTy+9R8tAKaCBOQAAeFY4 From: "Christian Huitema" To: "J. Noel Chiappa" , Cc: X-OriginalArrivalTime: 20 Jul 2003 23:41:36.0331 (UTC) FILETIME=[755C79B0:01C34F18] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > But don't mistake these questions for the first question - of whether = you do > the separation. I would contend that modern applications already separate identity and = location. Take three different example, the web, SIP, and P2P file = sharing networks. In web applications, the objects are identified by an = http URL; in SIP, end points are identified by a SIP URL; in P2P = networks files are identified by their names and attributes. All of = these applications treat IP addresses strictly as locations -- some = place from which you can get a web page, to which you can send voice = packets, from which you can get a slice of a file. The specific IP = addresses vary over time, depending upon load balancing in web farms, = transient registrations in SIP, or which of the file publishers happens = to be on-line with P2P file sharing networks. P2P and the web, combined, = represent the bulk of current Internet traffic. In current networks, the identifier role of IP addresses is very = limited. The most visible in the current discussion is the use of = addresses to identify TCP connections, but we should add IPSEC = associations, and filtering rules encoded in some firewalls or similar = products. I would agree that these are problems, but they are limited in = scope. In fact, the market is responding to these issues when needed: = firewall traversal is now mostly based on VPN products, using explicit = identification of users and computers; IPSEC sessions often require the = exchange of identification tokens, independent of the IP address.=20 The question is not whether we want to separate the location and = identity function of IP addresses. Clearly, application developers have = voted on that one. They just use the location function, and rely on = other systems for identity. IP addresses should be locators, period. The = question is whether we want to pay an identifier tax at the IP layer. = The tax will be significant: additional resolution procedures, = additional overhead in the packets. The main justification of that tax = would be to keep alive some long duration TCP connections, or some IPSEC = sessions. This may benefit some applications, but the tax would have to = be payed by everybody, whether they need the functionality or not. I = would much rather not pay the identifier tax, and use a combination of = application level sessions, TCP improvement, IPSEC fast rekeying, or = maybe mobile-IP. There is no reason that everybody pays the tax when = just a few benefit. -- Christian Huitema From owner-multi6@ops.ietf.org Sun Jul 20 23:04:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04090 for ; Sun, 20 Jul 2003 23:04:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eQvg-0000Aj-20 for multi6-data@psg.com; Mon, 21 Jul 2003 03:01:36 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.14) id 19eQvd-000097-Kc for multi6@ops.ietf.org; Mon, 21 Jul 2003 03:01:33 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id BEBD334460; Sun, 20 Jul 2003 20:18:30 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6L30vYB009714; Sun, 20 Jul 2003 20:00:57 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Fwd: Minutes / Notes Date: Sun, 20 Jul 2003 20:00:57 -0700 Message-ID: Thread-Topic: Fwd: Minutes / Notes Thread-Index: AcNPExXXncOVYR6hTy+9R8tAKaCBOQAAeFY4AAeAjlA= From: "Tony Li" To: "Christian Huitema" , "J. Noel Chiappa" , Cc: X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Christian, | The question is not whether we want to separate the=20 | location and identity function of IP addresses. Clearly,=20 | application developers have voted on that one. They just=20 | use the location function, and rely on other systems for=20 | identity. IP addresses should be locators, period. That would be just fine, if only we could. Unfortunately, we've put the IP address in the pseudo-header checksum, so when your locator changes, your connection fails. The entire discussion is about how we can use something else as an identifier. =20 Creating an identifier space is one way. Alternately, changing the pseudo-header would be another, but we discarded that as being even more unlikely. | The=20 | question is whether we want to pay an identifier tax at=20 | the IP layer. The tax will be significant: additional=20 | resolution procedures, additional overhead in the packets.=20 | The main justification of that tax would be to keep alive=20 | some long duration TCP connections, or some IPSEC=20 | sessions. This may benefit some applications, but the tax=20 | would have to be payed by everybody, whether they need the=20 | functionality or not. I would much rather not pay the=20 | identifier tax, and use a combination of application level=20 | sessions, TCP improvement, IPSEC fast rekeying, or maybe=20 | mobile-IP. There is no reason that everybody pays the tax=20 | when just a few benefit. The tax is somewhat simpler than you submit. Yes, it is an identifier and a locator in some small proportion of the packets. Perhaps just in the TCP SYN and SYN ACK. It is certainly a few more DNS records. This can certainly be paid only by those sites that want the benefits. No one is requiring any changes to vanilla IPv6 hosts. The advantages go to those hosts that are multi-homed, and that has typically been about 10% of the sites out there. [Aside: I suspect that this will grow as the Internet gets 'bushier'.] The advantages also go to their correspondent hosts. Now, if you don't want to play, I understand, but doing something to fix the current situation is absolutely essential. We cannot have scalable routing with PI addresses. These are also a tax on everyone and a much higher tax where we can ill afford it. Tony =20 From owner-multi6@ops.ietf.org Mon Jul 21 01:08:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05803 for ; Mon, 21 Jul 2003 01:08:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eSsC-0009Gf-8e for multi6-data@psg.com; Mon, 21 Jul 2003 05:06:08 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19eSsA-0009Es-18 for multi6@ops.ietf.org; Mon, 21 Jul 2003 05:06:06 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 20 Jul 2003 22:06:00 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 20 Jul 2003 22:06:02 -0700 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 20 Jul 2003 22:05:53 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 20 Jul 2003 22:05:45 -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); Sun, 20 Jul 2003 22:05:52 -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.0); Sun, 20 Jul 2003 22:06:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: Fwd: Minutes / Notes Date: Sun, 20 Jul 2003 22:01:38 -0700 Message-ID: Thread-Topic: Fwd: Minutes / Notes Thread-Index: AcNPExXXncOVYR6hTy+9R8tAKaCBOQAAeFY4AAeAjlAABIxWmA== From: "Christian Huitema" To: "Tony Li" , "J. Noel Chiappa" , Cc: X-OriginalArrivalTime: 21 Jul 2003 05:06:06.0365 (UTC) FILETIME=[CA67E4D0:01C34F45] X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Now, if you don't want to play, I understand, but doing something > to fix the current situation is absolutely essential. We cannot > have scalable routing with PI addresses. These are also a tax on > everyone and a much higher tax where we can ill afford it. I definitely believe that we need a solution for multi-homed sites. I = just want to make sure that whatever tax we create is only paid by those = who benefit from multi-homing, i.e. multi-homed hosts and their = correspondents. Moreover, I submit that the tax should only be paid py = those applications that actually benefit from TCP resiliency, i.e. those = whose "mean connection time" is not small compared to the "mean time = between rehoming events". Even so, applications that have their own = identification and reconnection mechanisms should not have to pay the = identifier tax. -- Christian Huitema From owner-multi6@ops.ietf.org Mon Jul 21 02:17:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18502 for ; Mon, 21 Jul 2003 02:17:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eTxV-000Edy-SS for multi6-data@psg.com; Mon, 21 Jul 2003 06:15:41 +0000 Received: from [65.174.124.36] (helo=dmz1.procket.com) by psg.com with esmtp (Exim 4.14) id 19eTxS-000EVd-Kb for multi6@ops.ietf.org; Mon, 21 Jul 2003 06:15:38 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id F40E823C5F; Sun, 20 Jul 2003 23:18:08 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6L6F4YB015029; Sun, 20 Jul 2003 23:15:04 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Fwd: Minutes / Notes Date: Sun, 20 Jul 2003 23:15:04 -0700 Message-ID: Thread-Topic: Fwd: Minutes / Notes Thread-Index: AcNPExXXncOVYR6hTy+9R8tAKaCBOQAAeFY4AAeAjlAABIxWmAACgcSw From: "Tony Li" To: "Christian Huitema" , "J. Noel Chiappa" , Cc: X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I think a tax that is of a bigger concern is that we need to affect most of the predominant implementations out there. Once we get past that hurdle, having a host that knows that it's multi-homed or it's corresponding with a multi-homed host is a small additional tax with substantial benefits. Tony | -----Original Message----- | From: Christian Huitema [mailto:huitema@windows.microsoft.com]=20 | Sent: Sunday, July 20, 2003 10:02 PM | To: Tony Li; J. Noel Chiappa; multi6@ops.ietf.org | Cc: jnc@ginger.lcs.mit.edu | Subject: RE: Fwd: Minutes / Notes | =20 | =20 | > Now, if you don't want to play, I understand, but doing something | > to fix the current situation is absolutely essential. We cannot | > have scalable routing with PI addresses. These are also a tax on | > everyone and a much higher tax where we can ill afford it. | =20 | I definitely believe that we need a solution for=20 | multi-homed sites. I just want to make sure that whatever=20 | tax we create is only paid by those who benefit from=20 | multi-homing, i.e. multi-homed hosts and their=20 | correspondents. Moreover, I submit that the tax should=20 | only be paid py those applications that actually benefit=20 | from TCP resiliency, i.e. those whose "mean connection=20 | time" is not small compared to the "mean time between=20 | rehoming events". Even so, applications that have their=20 | own identification and reconnection mechanisms should not=20 | have to pay the identifier tax. | =20 | -- Christian Huitema | =20 | =20 | =20 From owner-multi6@ops.ietf.org Mon Jul 21 02:46:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19327 for ; Mon, 21 Jul 2003 02:46:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eUPN-000GX0-6R for multi6-data@psg.com; Mon, 21 Jul 2003 06:44:29 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19eUPE-000GWg-5C for multi6@ops.ietf.org; Mon, 21 Jul 2003 06:44:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6L6hD619320; Mon, 21 Jul 2003 09:43:14 +0300 Date: Mon, 21 Jul 2003 09:43:13 +0300 (EEST) From: Pekka Savola To: Joe Abley cc: Brian E Carpenter , Subject: Re: Minutes / Notes In-Reply-To: <3E1678D6-B931-11D7-9A86-00039312C852@isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-28.2 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 18 Jul 2003, Joe Abley wrote: > > ISPs' networks don't crash every other day (if they do, change the > > ISPs; > > we just can't design protocols to work around broken operational > > practices: that's going to fail, no matter what). Might happen a > > couple > > of times during the year, at most, but I'm not convinced that's > > necessarily a huge problem. > > This isn't about ISPs' networks "crashing" -- it's about transient > changes in routing topology, which *do* happen with monotonous > regularity (circuits fail, or take errors and have to be shut down; > upstream providers fat-finger routing policy and stopping routes from > propagating, etc). Fat-fingering in critical places is a real problem -- more so than many other problems like circuit failures, but most of these are not visible to the edge network. > Also remember that the effects of a re-homing event > can be felt several levels down; if your path to the DFZ is through > three intermediate ASes, then you're three-times as likely to feel the > impact of a re-homing event if the multihoming architecture presents an > impact to be felt. In some countries, *all* the ISPs are two or three > ASes away from the core. Nope, it's not as simple as that. Please remember the context here: we're talking about the connection surviability of the end-user. What happens several AS's upstream doesn't typically matter *at all*. Sure, some circuit goes down, and traffic gets re-routed. These almost always cause a quick re-routing, not e.g. falling back to BGP hello timeouts. These are not things that are (typically) visible to the end-users, and do not trigger rehoming events. The most important things, as it seems to me, are: - your own resiliency - the connection between you and your ISP(s) - your first-hop ISP's network characteristics, configuration, etc. So, in this context, I'm not sure that in practice the connection survivability is a strict requirement. IMHO, the quality of your first-hop ISP is the thing that matters the most. -- 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 Mon Jul 21 02:53:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19396 for ; Mon, 21 Jul 2003 02:53:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eUYD-000H7h-Lh for multi6-data@psg.com; Mon, 21 Jul 2003 06:53:37 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19eUYA-000H7S-HL for multi6@ops.ietf.org; Mon, 21 Jul 2003 06:53:34 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6L6rUa19387; Mon, 21 Jul 2003 09:53:30 +0300 Date: Mon, 21 Jul 2003 09:53:30 +0300 (EEST) From: Pekka Savola To: marcelo bagnulo cc: Brian E Carpenter , Subject: RE: Fwd: Minutes / Notes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-30.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 20 Jul 2003, marcelo bagnulo wrote: > > However, I also think that one must apply some reason here. For example, > > if you have have tunnels from two access routers to two ISP's ("site exit > > routers approach"), I don't think you have to care about connection > > survivability that much. > > > > ISPs' networks don't crash every other day (if they do, change the ISPs; > > we just can't design protocols to work around broken operational > > practices: that's going to fail, no matter what). Might happen a couple > > of times during the year, at most, but I'm not convinced that's > > necessarily a huge problem. > > Do you think that this is an acceptable solution fo very small sites? > I mean, suppose an scenario where very small site multihoming becomes very > frequent, so the number of those sites is very high. > site Exit router approach requires manual configuration of the tunnels by > both ISPs, so do you think that isps will be willing to do this for very > small sites? I don't really think the "site-exit routers approach" scales for very small sites ("home networks"). But then again, my perception is that very small sites can easily live without connection surviability. These aren't really mission-critical systems, systems where network downtime could cost e.g. 1000$ a minute. The ability to start new connections using the other connectivity is probably good enough for most folks. When one says "very small sites", you could count inside that a guy who has a mobile terminal and has e.g. GPRS and WLAN interfaces (or something else), a laptop, and wants to keep his connections open while he moves or switches between the two. Sounds like the Mobile IPv6 problem space to me. > An complementary approach would be to use some sort of tunnel broker so that > the site itself could configure its own tunnels, so the isps operators do > not have to deal with this, what do you think? If something like this would be required, I would certainly guess that there would be some mechanism for automation, be it using some DHCP prefix delegation extension, or whatever. However, I haven't really thought about it, and I would really rather see that those very small sites don't require any mechanisms which require anything other that very light-weight infrastructure. -- 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 Mon Jul 21 04:12:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20693 for ; Mon, 21 Jul 2003 04:12:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eVl7-000LTT-MG for multi6-data@psg.com; Mon, 21 Jul 2003 08:11:01 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19eVl5-000LPl-6H for multi6@ops.ietf.org; Mon, 21 Jul 2003 08:10:59 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id C6AC223; Mon, 21 Jul 2003 11:20:06 +0300 (EEST) Message-ID: <3F1B9FF2.6050801@nomadiclab.com> Date: Mon, 21 Jul 2003 11:10:26 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: marcelo bagnulo , multi6@ops.ietf.org Subject: Re: Minutes / Notes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > Having the source identifier rather than a source locator in packets > might be useful. That might form a serious privacy problem, as I mentioned in an earlier message. > The ingress filtering issue is a bigger issue. If the source address field semantics is changed to record the route rather than to contain an address that is filtered, the problem gets trivially solved. That change does *not* change routers that are not aware of the change. Hence, such a change can be made incrementally, without any flag days. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Jul 21 06:41:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23490 for ; Mon, 21 Jul 2003 06:41:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eY56-00050R-J0 for multi6-data@psg.com; Mon, 21 Jul 2003 10:39:48 +0000 Received: from [208.185.30.208] (helo=buffoon.automagic.org ident=qmailr) by psg.com with smtp (Exim 4.14) id 19eY51-00050B-SK for multi6@ops.ietf.org; Mon, 21 Jul 2003 10:39:43 +0000 Received: (qmail 47822 invoked by uid 0); 21 Jul 2003 10:39:42 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 21 Jul 2003 10:39:42 -0000 Date: Mon, 21 Jul 2003 06:39:52 -0400 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Brian E Carpenter , To: Pekka Savola From: Joe Abley In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, Jul 21, 2003, at 02:43 Canada/Eastern, Pekka Savola wrote: >> Also remember that the effects of a re-homing event >> can be felt several levels down; if your path to the DFZ is through >> three intermediate ASes, then you're three-times as likely to feel the >> impact of a re-homing event if the multihoming architecture presents >> an >> impact to be felt. In some countries, *all* the ISPs are two or three >> ASes away from the core. > > Nope, it's not as simple as that. > > Please remember the context here: we're talking about the connection > surviability of the end-user. What happens several AS's upstream > doesn't > typically matter *at all*. Sure, some circuit goes down, and traffic > gets > re-routed. These almost always cause a quick re-routing, not e.g. > falling > back to BGP hello timeouts. These are not things that are (typically) > visible to the end-users, and do not trigger rehoming events. Right, that's the case right now. However, if a re-homing event between the user and the DFZ forces a renumbering event (for example), and there's no transport-layer support for session stability over that renumbering event, then the user will see their sessions die. > The most important things, as it seems to me, are: > - your own resiliency > - the connection between you and your ISP(s) > - your first-hop ISP's network characteristics, configuration, etc. That is the case with today's IPv4 multi-homing, since the multi-homing model provides endpoint address stability. In the case of an alternate multi-homing model which doesn't provide address stability, users will feel pain. > So, in this context, I'm not sure that in practice the connection > survivability is a strict requirement. IMHO, the quality of your > first-hop ISP is the thing that matters the most. Joe From owner-multi6@ops.ietf.org Mon Jul 21 07:01:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23990 for ; Mon, 21 Jul 2003 07:01:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eYPh-0006cO-OE for multi6-data@psg.com; Mon, 21 Jul 2003 11:01:05 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19eYPd-0006ai-Sc for multi6@ops.ietf.org; Mon, 21 Jul 2003 11:01:02 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6LAxoZ21335; Mon, 21 Jul 2003 13:59:50 +0300 Date: Mon, 21 Jul 2003 13:59:49 +0300 (EEST) From: Pekka Savola To: Joe Abley cc: Brian E Carpenter , Subject: Re: Minutes / Notes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 21 Jul 2003, Joe Abley wrote: > >> Also remember that the effects of a re-homing event > >> can be felt several levels down; if your path to the DFZ is through > >> three intermediate ASes, then you're three-times as likely to feel the > >> impact of a re-homing event if the multihoming architecture presents > >> an > >> impact to be felt. In some countries, *all* the ISPs are two or three > >> ASes away from the core. > > > > Nope, it's not as simple as that. > > > > Please remember the context here: we're talking about the connection > > surviability of the end-user. What happens several AS's upstream > > doesn't typically matter *at all*. Sure, some circuit goes down, and > > traffic gets re-routed. These almost always cause a quick re-routing, > > not e.g. falling back to BGP hello timeouts. These are not things > > that are (typically) visible to the end-users, and do not trigger > > rehoming events. > > Right, that's the case right now. > > However, if a re-homing event between the user and the DFZ forces a > renumbering event (for example), and there's no transport-layer support > for session stability over that renumbering event, then the user will > see their sessions die. Indeed. I don't think this is all that common case, though. I'd really wish to know of events like these in the DFZ that caused a re-routing delay long enough (e.g. over 30 secs) to be an annoyance. > > The most important things, as it seems to me, are: > > - your own resiliency > > - the connection between you and your ISP(s) > > - your first-hop ISP's network characteristics, configuration, etc. > > That is the case with today's IPv4 multi-homing, since the multi-homing > model provides endpoint address stability. In the case of an alternate > multi-homing model which doesn't provide address stability, users will > feel pain. Yes. Which is why multiple PA + a tunnel through a second ISP is actually a rather good solution (IMHO). Not enough for everybody, certainly, but good nonetheless. -- 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 Mon Jul 21 07:23:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24480 for ; Mon, 21 Jul 2003 07:23:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eYkc-0007zV-PN for multi6-data@psg.com; Mon, 21 Jul 2003 11:22:42 +0000 Received: from [208.185.30.208] (helo=buffoon.automagic.org ident=qmailr) by psg.com with smtp (Exim 4.14) id 19eYka-0007zC-Bw for multi6@ops.ietf.org; Mon, 21 Jul 2003 11:22:40 +0000 Received: (qmail 50768 invoked by uid 0); 21 Jul 2003 11:22:39 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 21 Jul 2003 11:22:39 -0000 Date: Mon, 21 Jul 2003 07:22:46 -0400 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Brian E Carpenter , To: Pekka Savola From: Joe Abley In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, Jul 21, 2003, at 06:59 Canada/Eastern, Pekka Savola wrote: > On Mon, 21 Jul 2003, Joe Abley wrote: > >> However, if a re-homing event between the user and the DFZ forces a >> renumbering event (for example), and there's no transport-layer >> support >> for session stability over that renumbering event, then the user will >> see their sessions die. > > Indeed. > > I don't think this is all that common case, though. I'd really wish to > know of events like these in the DFZ that caused a re-routing delay > long > enough (e.g. over 30 secs) to be an annoyance. It's not at all a common case right now, because right now re-homing events are handled in the v4 network today without anybody having to renumber. The issue of whether path instability causes session resets is different. I don't think it happens very often (unless accompanied by rapid route flapping which causes prefixes to be damped out for noticable periods), but I don't know of any formal study. Joe From owner-multi6@ops.ietf.org Mon Jul 21 10:33:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29309 for ; Mon, 21 Jul 2003 10:33:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ebgr-000KGz-IQ for multi6-data@psg.com; Mon, 21 Jul 2003 14:31:01 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.14) id 19ebgo-000KG9-Dm for multi6@ops.ietf.org; Mon, 21 Jul 2003 14:30:58 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6LEUKUg015212; Mon, 21 Jul 2003 07:30:21 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6LEUFQ04828; Mon, 21 Jul 2003 16:30:16 +0200 (MEST) Date: Mon, 21 Jul 2003 16:28:22 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Fwd: Minutes / Notes To: Christian Huitema Cc: "J. Noel Chiappa" , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-9.5 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > I would contend that modern applications already separate identity and > location. Take three different example, the web, SIP, and P2P file sharing > networks. In web applications, the objects are identified by an http URL; in > SIP, end points are identified by a SIP URL; in P2P networks files are > identified by their names and attributes. All of these applications treat IP > addresses strictly as locations -- some place from which you can get a web > page, to which you can send voice packets, from which you can get a slice of > a file. The specific IP addresses vary over time, depending upon load > balancing in web farms, transient registrations in SIP, or which of the file > publishers happens to be on-line with P2P file sharing networks. P2P and the > web, combined, represent the bulk of current Internet traffic. Christian, I'm trying to reconcile the above with other things we are hearing: 1. the lack of a multihoming solution in IPv6 is a hindrance to deployment 2. the lack of PI space in IPv6 (whether or not multihoming) is a hindrance to deployment If the folks concerned about #1 shared your view then presumably the only thing we would need would be multiaddressing and a fix for the interaction between source address selection and ingress filtering and we would have solved #1. However, there might be strong perception out there that IPv4 multihoming handles applications that do not have their own identifier hence folks want to see IPv6 supporting the same thing, even if applications are moving towards their own identifier space and application layer retries upon failures. Even if we believed that a fix in source address selection + ingress filtering was sufficient for #1 it doesn't seem to address the perception of #2. I get the feeling that folks have been burned by renumbering when switching ISPs in IPv4 and they never want to do that again, so convincing them that the renumbering tools in IPv6 plus applications having their own identifiers and retry logic is a good enough solution seems like a hard sell. [Not that ID/loc separation makes everything use the PI identifiers; there will presumably still be filtering in firewalls etc applied to loctors. But it sure would reduce the pain of renumbering.] So do you think that fixing source address selection + ingress filtering would be sufficient to address perception 1 and 2? > The question is not whether we want to separate the location and identity > function of IP addresses. Clearly, application developers have voted on that > one. They just use the location function, and rely on other systems for > identity. IP addresses should be locators, period. The question is whether > we want to pay an identifier tax at the IP layer. The tax will be > significant: additional resolution procedures, additional overhead in the > packets. The main justification of that tax would be to keep alive some long > duration TCP connections, or some IPSEC sessions. This may benefit some > applications, but the tax would have to be payed by everybody, whether they > need the functionality or not. I would much rather not pay the identifier > tax, and use a combination of application level sessions, TCP improvement, > IPSEC fast rekeying, or maybe mobile-IP. There is no reason that everybody > pays the tax when just a few benefit. Good point. Presumably applications that don't need the benefits of the identifiers can operate on the locators and not incur any overhead at the IP layer. Erik From owner-multi6@ops.ietf.org Mon Jul 21 11:17:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00516 for ; Mon, 21 Jul 2003 11:17:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ecPB-000NO3-3A for multi6-data@psg.com; Mon, 21 Jul 2003 15:16:49 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.14) id 19ecP8-000NNM-G1 for multi6@ops.ietf.org; Mon, 21 Jul 2003 15:16:46 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6LFG2oF012723; Mon, 21 Jul 2003 08:16:03 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6LFFwQ08581; Mon, 21 Jul 2003 17:15:59 +0200 (MEST) Date: Mon, 21 Jul 2003 16:17:11 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Fwd: Minutes / Notes To: marcelo bagnulo Cc: "J. Noel Chiappa" , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: QUOTED-PRINTABLE > So, i guess that you need to carry the locator of the destination, since = it > is needed to forward the packet to the destination. > I guess that you don=B4t need to carry the destination identifier in all > packets. > For the source endpoint information, i am not sure. > I think that carrying the source identifier would make more sense, since = it > identifies the other endd of the communication.=20 For the source part (locator vs. id) we need to understand how multicast routing would work. Today it applies RPF to the source address and uses the hierarchical structure of the source address to aggregate the information u= sed by the RPF. If the source identifiers are not aggregatable this will be an issue. > This would also allow to > configure filters depending on the source identifier making things like > renumbering easier. The first problem that i find with this option is tha= t > you cannot send error messages back to the source (since there is no loca= tor > of the source) when there is a problem and additional mechanisms are need= ed > to perform reverse mapping in this situation. The ability to return packets without much overhead, such as an ICMP error = or a TCP SYN, might be important to avoid a class of DoS attacks om routers. Having the source locator in the packet means that an ICMP error can be generated without performing any ID->locator mapping Erik From owner-multi6@ops.ietf.org Mon Jul 21 11:17:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00553 for ; Mon, 21 Jul 2003 11:17:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ecOo-000NNd-Cp for multi6-data@psg.com; Mon, 21 Jul 2003 15:16:26 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.14) id 19ecOl-000NNN-Tm for multi6@ops.ietf.org; Mon, 21 Jul 2003 15:16:23 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6LFG9CW007704; Mon, 21 Jul 2003 09:16:10 -0600 (MDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6LFG5Q08585; Mon, 21 Jul 2003 17:16:06 +0200 (MEST) Date: Mon, 21 Jul 2003 16:17:14 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Source address selection in IPv6 multihomed multi-addressed sites To: Iljitsch van Beijnum Cc: Cedric de Launois , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > So it is assumed that ISPs will filter their customer's traffic and > only let packets with valid source addresses through. This gives us a > range of options: > > 1. do nothing (what we do today) -> traffic will regularly not make it > through -> a lot of unhappiness > 2. ask ISP to let traffic through -> ISP may say no -> much unhappiness > or upstream ISP filters -> also unhappiness > 3. figure out the right source address (sort of happens today > automatically sometimes) -> traffic will get through, but if the > destination is rerouted over the other link the session breaks -> still > considerable unhappiness > 4. do source address dependent routing -> easy when only one box does > this, harder in sites where there is internal routing, still problems > with routing changes And 5: have the site border router rewrite the source locator. This assumes that id/locators are split, that the rewriting doesn't effect "legacy packets" (without the id/loc split), and that the system for securely verifying the id/locator relationship can handle such rewriting. Thus understanding the tradeoff between source locator rewriting and other parts of the system is important. Erik From owner-multi6@ops.ietf.org Mon Jul 21 12:10:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02156 for ; Mon, 21 Jul 2003 12:10:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19edDu-0000wp-JO for multi6-data@psg.com; Mon, 21 Jul 2003 16:09:14 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.14) id 19edDe-0000uH-GS for multi6@ops.ietf.org; Mon, 21 Jul 2003 16:08:58 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h6LG8utU005598; Mon, 21 Jul 2003 12:08:56 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h6LG8unC005595; Mon, 21 Jul 2003 12:08:56 -0400 Date: Mon, 21 Jul 2003 12:08:56 -0400 From: "J. Noel Chiappa" Message-Id: <200307211608.h6LG8unC005595@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: Fwd: Minutes / Notes Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Christian Huitema" >> If you have two separate multi-homing mechanisms, then the cost, in >> system complexity, implementation size, amount of protocol >> specification work needed, etc, etc just seems to me out of all >> proportion to the benefit. .. Pick one. > Frankly, I am not sure about the "pick one". It supposes that we know > exactly what we want to design, and that we can commit to one right > now. That's the job of an architect - to see things at a deeper level than just today's requirements, to see past them to the fundamental basics and create structures with lasting utility. > a fundamental design choice) is the layer at which identifiers are > maintain. Is it IP, transport or session? .. It is very unclear to me > that IP would in fact be the right layer for the job. This is an interesting point, because I've often thought that with a blank slate, perhaps a better allocation of mechanism to layers of functional abstraction might be possible. E.g. when I think about maintaining a connection to something like a pool of servers, you might move functions around to different layers. However, we have to live with the system we've got, and it still seems to me that as long as we have an end-end reliable stream level which is fairly ubiquitous (i.e. TCP), and we have the routing architecture we've got, and we want the system overall to have certain capabilities (e.g. mobility, switching to a different multi-homed inbound link), then that layer needs names for the entities. > Another quite important design choice is the scope of the identifier. > .. The scope of an identifier system, by definition, has to be wider. > Yet, we don't really know how wide. Is it a host? .. Consider clusters > on one hand, multi-user systems on the other. Would you have an > identifier per node in the cluster, or one per user in a multi-user > system? What about process mobility? One of the fundamental concepts of the end-end reliable stream layer is the notion of fate-sharing. So I have said, for many years now, that the thing that needs to be named by an end-end RSL name is a fate-sharing region. E.g. if you have two machines in a pool, and one is (temporarily) handling a TCP connection, and the other doesn't have all the latest TCP state information to take over the connection if the first one fails, then the two are not a fate-sharing region, and cannot share an end-end RSL name. > I heard many say during the multi6 debate that applications cannot > possibly handle multiple addresses well. To disprove that, I suggest > you take a look at the variations of "swarmcast" implemented by P2P > systems .. Such a system would handle multi-addressing beautifully. By definition, if we do multi-homing with multiple addresses, *something* is going to have to handle multiple addresses. It may be the application (some will no doubt care), it may be some other layer. But you only have a need for a separate name for the end-end entity *if you wish to provide certain functionalities*, e.g. mobility, or multi-homing, or anything that (in general) requires the ability to switch to a different address while the connection to that end-end entity is active. (And don't forget, a set of addresses is an end-end name, too... viz SCTP.) > But my real point when bringing up the P2P example is that innovation > happens. .. Office automation systems use transaction processing. The > list goes on. What we are observing is a distributed innovation process > arbitraged by the market place. I trust that much more than a > identifier/location split designed by committee. Yes, and they all are working within an architectural framework that was thought out in advance to provide the kind of flexibility needed to do this, by providing certain key fundamentals, and leaving the rest open. What we need to do here is identify the key architectural fundamentals, and provide them. Noel From owner-multi6@ops.ietf.org Mon Jul 21 12:35:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02926 for ; Mon, 21 Jul 2003 12:35:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19edcn-0002ZI-37 for multi6-data@psg.com; Mon, 21 Jul 2003 16:34:57 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.14) id 19edci-0002Ym-TY for multi6@ops.ietf.org; Mon, 21 Jul 2003 16:34:52 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id EBC9934489; Mon, 21 Jul 2003 09:51:49 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6LGYLYB028596; Mon, 21 Jul 2003 09:34:21 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Minutes / Notes Date: Mon, 21 Jul 2003 09:34:21 -0700 Message-ID: Thread-Topic: Minutes / Notes Thread-Index: AcNPnj0RbdMP/PJdQXK+AIF6zt3ufwAB1U4A From: "Tony Li" To: "Erik Nordmark" , "marcelo bagnulo" Cc: "J. Noel Chiappa" , X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable | =20 | > So, i guess that you need to carry the locator of the=20 | destination, since it | > is needed to forward the packet to the destination. | > I guess that you don=B4t need to carry the destination=20 | identifier in all | > packets. | > For the source endpoint information, i am not sure. | > I think that carrying the source identifier would make=20 | more sense, since it | > identifies the other endd of the communication.=20 | =20 | For the source part (locator vs. id) we need to understand=20 | how multicast | routing would work. Today it applies RPF to the source=20 | address and uses the | hierarchical structure of the source address to aggregate=20 | the information used | by the RPF. If the source identifiers are not aggregatable=20 | this will be an | issue. For multicast, the source address needs to be the locator, NOT the identifier. RPF is a topological computation. | The ability to return packets without much overhead, such=20 | as an ICMP error or | a TCP SYN, might be important to avoid a class of DoS=20 | attacks om routers. Important, yes, but not because of DoS effects. Just simple rate-of-return arguments suggest that routers will do a better "best effort" job of returning errors if they don't have to jump through hoops. And unlike hosts, the router cannot maintain an effective cache of all of the sources that might send it erroneous packets. | Having the source locator in the packet | means that an ICMP error can be generated without performing | any ID->locator mapping Concur. IMHO, this is a pragmatic necessity. Tony From owner-multi6@ops.ietf.org Mon Jul 21 12:56:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03489 for ; Mon, 21 Jul 2003 12:56:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19edwb-0004Er-9w for multi6-data@psg.com; Mon, 21 Jul 2003 16:55:25 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19edwY-0004ER-5r for multi6@ops.ietf.org; Mon, 21 Jul 2003 16:55:22 +0000 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 21 Jul 2003 09:55:22 -0700 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 21 Jul 2003 09:55:21 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 21 Jul 2003 09:55:23 -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); Mon, 21 Jul 2003 09:55:22 -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.0); Mon, 21 Jul 2003 09:55:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: Fwd: Minutes / Notes Date: Mon, 21 Jul 2003 09:55:18 -0700 Message-ID: Thread-Topic: Fwd: Minutes / Notes Thread-Index: AcNPExXXncOVYR6hTy+9R8tAKaCBOQAAeFY4AAeAjlAABIxWmAACgcSwABZCY7A= From: "Christian Huitema" To: "Tony Li" , "J. Noel Chiappa" , Cc: X-OriginalArrivalTime: 21 Jul 2003 16:55:11.0322 (UTC) FILETIME=[D92D23A0:01C34FA8] X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I think a tax that is of a bigger concern is that we need to affect most > of the predominant implementations out there. Once we get past that > hurdle, having a host that knows that it's multi-homed or it's > corresponding > with a multi-homed host is a small additional tax with substantial > benefits. I don't know about most implementations. We definitely need a solution that is "upward compatible" with the current implementations, so we should assume that there will be co-existence for a long time. And I could definitely see why some implementations would just decide to forget the benefits of multi-homing, or at least those of TCP survivability. But I am concerned mostly with the tax on applications that run on a multi-homed system, yet are perfectly happy dealing directly with addresses/locators. I would assert that this is the bulk of current applications. -- Christian Huitema=20 From owner-multi6@ops.ietf.org Mon Jul 21 13:39:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04828 for ; Mon, 21 Jul 2003 13:39:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eebR-0007FK-5F for multi6-data@psg.com; Mon, 21 Jul 2003 17:37:37 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19eebO-0007CR-Ls for multi6@ops.ietf.org; Mon, 21 Jul 2003 17:37:34 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 19D851C; Mon, 21 Jul 2003 20:46:42 +0300 (EEST) Message-ID: <3F1C24BF.1060306@nomadiclab.com> Date: Mon, 21 Jul 2003 20:37:03 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li Cc: Erik Nordmark , multi6@ops.ietf.org Subject: Re: Minutes / Notes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-28.8 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | The ability to return packets without much overhead, such > | as an ICMP error or > | a TCP SYN, might be important to avoid a class of DoS > | attacks om routers. > > > Important, yes, but not because of DoS effects. Just simple > rate-of-return arguments suggest that routers will do a better > "best effort" job of returning errors if they don't have to jump > through hoops. And unlike hosts, the router cannot maintain an > effective cache of all of the sources that might send it erroneous > packets. Recording a route in a packet, if designed right, allows error messages to be returned to the source. Recording a route has the additional benefit that the information is always right. You don't need to configure your ingress filters. Since the routers record the path to the field, you know exactly the path the packet took. There are engineering challenges, though, and it may be impractical to implement it. The important point is, however, that if the id/loc separation is done, the source address is not needed by the end-hosts any more. It is needed in the very first packet flowing in a direction, and perhaps in the second one, until the id->loc state is verified and established, but not after that. We discuss this in length in our 2001 Nordsec paper, as I mentioned already. In that paper we discuss the point from the IPsec point of view, but most of the discussion directly applies to the id/loc separation point-of-view. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Jul 21 13:41:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04918 for ; Mon, 21 Jul 2003 13:41:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eef1-0007ao-HJ for multi6-data@psg.com; Mon, 21 Jul 2003 17:41:19 +0000 Received: from [65.174.124.36] (helo=dmz1.procket.com) by psg.com with esmtp (Exim 4.14) id 19eeey-0007Wq-Ss for multi6@ops.ietf.org; Mon, 21 Jul 2003 17:41:16 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 361FA23C64; Mon, 21 Jul 2003 10:43:11 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6LHefYB001172; Mon, 21 Jul 2003 10:40:41 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Fwd: Minutes / Notes Date: Mon, 21 Jul 2003 10:40:41 -0700 Message-ID: Thread-Topic: Fwd: Minutes / Notes Thread-Index: AcNPExXXncOVYR6hTy+9R8tAKaCBOQAAeFY4AAeAjlAABIxWmAACgcSwABZCY7AAAYLPQA== From: "Tony Li" To: "Christian Huitema" , "J. Noel Chiappa" , Cc: X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable | I don't know about most implementations. We definitely=20 | need a solution | that is "upward compatible" with the current implementations, so we | should assume that there will be co-existence for a long=20 | time. And I | could definitely see why some implementations would just decide to | forget the benefits of multi-homing, or at least those of TCP | survivability. But I am concerned mostly with the tax on=20 | applications | that run on a multi-homed system, yet are perfectly happy dealing | directly with addresses/locators. I would assert that this=20 | is the bulk | of current applications. Back in Ye Olden CIDR days, we estimated that about 10% of all sites were multihomed and that the most common ones were large enterprises. Those same large enterprises typically run a large variety of different OS's, so to provide this benefit, we clearly need to hit a high=20 percentage of the v6 implementations. The size of the tax is not high. If we work it so that we exchange identifiers as a TCP option only on SYNs, then we're talking about something like 40 bytes of additional overhead. And this is in a packet that is normally quite small. I realize that there are some applications out there that could be munged to handle addresses and locators. However, changing them one at a time is both architecturally ugly and very unlikely to let us make substantial forward progress. While this may well be the bulk of current applications, our job is not to architect for today's applications. It's to deal with tomorrow's. Tony From owner-multi6@ops.ietf.org Mon Jul 21 13:45:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05012 for ; Mon, 21 Jul 2003 13:45:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eehk-0007mw-Ko for multi6-data@psg.com; Mon, 21 Jul 2003 17:44:08 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19eehi-0007l1-83 for multi6@ops.ietf.org; Mon, 21 Jul 2003 17:44:06 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 2E8771C; Mon, 21 Jul 2003 20:53:14 +0300 (EEST) Message-ID: <3F1C2647.9060704@nomadiclab.com> Date: Mon, 21 Jul 2003 20:43:35 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: multi6@ops.ietf.org Subject: Source addresses and multicast (was Re: Fwd: Minutes / Notes) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, Erik Nordmark wrote: > For the source part (locator vs. id) we need to understand how multicast > routing would work. Today it applies RPF to the source address and uses the > hierarchical structure of the source address to aggregate the information used > by the RPF. If the source identifiers are not aggregatable this will be an > issue. I have to admit my ignorance here. Any pointers that would allow me to better understand what you say above? Especially, I don't understand if the "source" address you talk about is the source address in a packet, or the addresses (locators) of the members of a multicast group. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Jul 21 20:15:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15528 for ; Mon, 21 Jul 2003 20:15:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eklp-0000n9-NS for multi6-data@psg.com; Tue, 22 Jul 2003 00:12:45 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.14) id 19ekln-0000mx-6h for multi6@ops.ietf.org; Tue, 22 Jul 2003 00:12:43 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h6M0CctU008367; Mon, 21 Jul 2003 20:12:38 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h6M0CcbU008364; Mon, 21 Jul 2003 20:12:38 -0400 Date: Mon, 21 Jul 2003 20:12:38 -0400 From: "J. Noel Chiappa" Message-Id: <200307220012.h6M0CcbU008364@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Fwd: Minutes / Notes Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Keith Moore > the question should not be whether TCP connections should be able to > survive link failures - because clearly there are some kinds of link > failures that cannot possibly be survived. > A better question is: How long should an application be able to expect > a TCP connection to last without needing to implement its own > ack/retransmit/duplicate-suppression logic? My view is that a TCP > connection should not become a significant additional source of > failure. So it be able to last as long as its endpoints are likely to > stay "up" Aren't these two points in opposition to each other? You can't expect a TCP connection to survive a link failure - but TCP connections should stay up as long as the endpoints are up? Or are you assuming that the time between link failures is much, much higher than endpoint uptimes? I can tell you from experience (getting to MIT from here in VA) that that's not true! :-) Noel From owner-multi6@ops.ietf.org Mon Jul 21 20:24:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15798 for ; Mon, 21 Jul 2003 20:24:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ekwN-0001Ga-Sr for multi6-data@psg.com; Tue, 22 Jul 2003 00:23:39 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.14) id 19ekwL-0001GM-JR for multi6@ops.ietf.org; Tue, 22 Jul 2003 00:23:37 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h6M0NatU008449; Mon, 21 Jul 2003 20:23:36 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h6M0NZOw008448; Mon, 21 Jul 2003 20:23:35 -0400 Date: Mon, 21 Jul 2003 20:23:35 -0400 From: "J. Noel Chiappa" Message-Id: <200307220023.h6M0NZOw008448@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: Fwd: Minutes / Notes Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-1.6 required=5.0 tests=BAYES_30 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Tony Li" > Unfortunately, we've put the IP address in the pseudo-header checksum, > so when your locator changes, your connection fails. .. > Creating an identifier space is one way. Alternately, changing the > pseudo-header would be another, but we discarded that as being even > more unlikely. Hmmm. Why would adding a new namespace be any easier than changing the TCP checksum? In either event, if you're multihomed, and you want to interoperate with hosts elsewhere, they have to be modified before you can talk to them. Actually, this leads me to think. If interoperation with unmodified hosts is important, then all this discussion about alternative namespaces to identify endpoints is moot. At that point, there are precisely two mechanisms available: i) Use multiple addresses, and if the link whose address you're using for the connction fails, the connection fails. i) Wse multiple addresses, and if the link whose address you're using for the connction fails, use MIPv6 mechanisms to divert it to a backup address. Note that either of these can be used, and you can use whichever of these fits your needs best. This does tend to fill Brian's suggestion that we have a range of solutions available... Noel From owner-multi6@ops.ietf.org Mon Jul 21 20:41:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16125 for ; Mon, 21 Jul 2003 20:41:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19elCo-0002Ao-OM for multi6-data@psg.com; Tue, 22 Jul 2003 00:40:38 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19elCm-0002AP-Gb for multi6@ops.ietf.org; Tue, 22 Jul 2003 00:40:36 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 21 Jul 2003 17:40:29 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 21 Jul 2003 17:40:29 -0700 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 21 Jul 2003 17:40:29 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 21 Jul 2003 17:40:22 -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); Mon, 21 Jul 2003 17:40:34 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 21 Jul 2003 17:40:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: Fwd: Minutes / Notes Date: Mon, 21 Jul 2003 17:40:26 -0700 Message-ID: Thread-Topic: Fwd: Minutes / Notes Thread-Index: AcNP6NU8/6Y/WI2jSCilZdu/zFzouwAADqOA From: "Christian Huitema" To: "J. Noel Chiappa" , X-OriginalArrivalTime: 22 Jul 2003 00:40:27.0681 (UTC) FILETIME=[D89F7910:01C34FE9] X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Actually, this leads me to think. If interoperation with unmodified hosts > is > important, then all this discussion about alternative namespaces to > identify > endpoints is moot. At that point, there are precisely two mechanisms > available: >=20 > i) Use multiple addresses, and if the link whose address you're using for > the > connction fails, the connection fails. >=20 > i) Wse multiple addresses, and if the link whose address you're using for > the > connction fails, use MIPv6 mechanisms to divert it to a backup address. iii) Use multiple addresses, one of which is a "virtual address" that is guaranteed to be reachable all the time, albeit slowly. Use the virtual address to start connections. Use MIPv6 mechanisms to divert to an actual address. I mean, it is possible to design virtual networks using for example the distributed hash table technology. Or using a satellite network. Or a really big server with lots of redundancy. -- Christian Huitema From owner-multi6@ops.ietf.org Mon Jul 21 20:57:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16313 for ; Mon, 21 Jul 2003 20:57:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19elSg-0003DW-K0 for multi6-data@psg.com; Tue, 22 Jul 2003 00:57:02 +0000 Received: from [65.174.124.36] (helo=dmz1.procket.com) by psg.com with esmtp (Exim 4.14) id 19elSe-0003CG-1Q for multi6@ops.ietf.org; Tue, 22 Jul 2003 00:57:00 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id E00A923C66; Mon, 21 Jul 2003 17:58:13 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6M0uTYB017032; Mon, 21 Jul 2003 17:56:29 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Minutes / Notes Date: Mon, 21 Jul 2003 17:56:29 -0700 Message-ID: Thread-Topic: Minutes / Notes Thread-Index: AcNP6X82RF3Ga11PRe+o2qhuW2RcEQAAcA0w From: "Tony Li" To: "J. Noel Chiappa" , X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable | > Unfortunately, we've put the IP address in the=20 | pseudo-header checksum, | > so when your locator changes, your connection fails. ..=20 | > Creating an identifier space is one way.=20 | Alternately, changing the | > pseudo-header would be another, but we discarded=20 | that as being even | > more unlikely. | =20 | Hmmm. Why would adding a new namespace be any easier than=20 | changing the TCP | checksum?=20 Because the politics are easier. No, I don't like that, but it's very clear to me that pushing rocks up steep hills is harder than pushing rocks downhill. I'm learning to live with the political realities that I don't like and still make forward progress. | In either event, if you're multihomed, and you=20 | want to interoperate | with hosts elsewhere, they have to be modified before you=20 | can talk to them. They have to be modified before they can provide connection survivability. You still have basic connectivity. =20 | Actually, this leads me to think. If interoperation with=20 | unmodified hosts is | important, then all this discussion about alternative=20 | namespaces to identify | endpoints is moot. At that point, there are precisely two=20 | mechanisms | available: | =20 | i) Use multiple addresses, and if the link whose address=20 | you're using for the | connction fails, the connection fails. | =20 | i) Wse multiple addresses, and if the link whose address=20 | you're using for the | connction fails, use MIPv6 mechanisms to divert it to a=20 | backup address. | =20 | Note that either of these can be used, and you can use=20 | whichever of these | fits your needs best. This does tend to fill Brian's=20 | suggestion that we have | a range of solutions available... The design team came up with an alternative that did not=20 require a tunnel endpoint buried inside of an ISP network, used multiple PA addresses, and provided for connection survivability. It has the advantage(?) that locators and identifiers are both syntactically IPv6 addresses so that unmodified hosts can continue to function without difficulty. Yes, there are many different approaches to a specific solution, but the need to create the namespace and manage it is clearly overhead. We don't wish to multiply this by having a variety of implemented solutions. While that might ease the standards body politics, that would be effectively undeployable and thereby useless. Tony From owner-multi6@ops.ietf.org Tue Jul 22 02:25:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03110 for ; Tue, 22 Jul 2003 02:25:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eqXM-000JV7-0c for multi6-data@psg.com; Tue, 22 Jul 2003 06:22:12 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19eqXI-000JTt-AC for multi6@ops.ietf.org; Tue, 22 Jul 2003 06:22:08 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6M6LYW00349; Tue, 22 Jul 2003 09:21:35 +0300 Date: Tue, 22 Jul 2003 09:21:34 +0300 (EEST) From: Pekka Savola To: Pekka Nikander cc: Tony Li , Erik Nordmark , Subject: Re: Minutes / Notes In-Reply-To: <3F1C24BF.1060306@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-25.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 21 Jul 2003, Pekka Nikander wrote: > > | The ability to return packets without much overhead, such > > | as an ICMP error or > > | a TCP SYN, might be important to avoid a class of DoS > > | attacks om routers. > > > > > > Important, yes, but not because of DoS effects. Just simple > > rate-of-return arguments suggest that routers will do a better > > "best effort" job of returning errors if they don't have to jump > > through hoops. And unlike hosts, the router cannot maintain an > > effective cache of all of the sources that might send it erroneous > > packets. > > Recording a route in a packet, if designed right, allows error > messages to be returned to the source. Recording a route has > the additional benefit that the information is always right. > You don't need to configure your ingress filters. Since the > routers record the path to the field, you know exactly the path > the packet took. > > There are engineering challenges, though, and it may be > impractical to implement it. [...] Yes, and remember the how spammers got to forging the SMTP Received: headers. You really can't trust the recorded route: it may have any number of forged "bogus" entries. However, at least a part of that trail is always valid -- it's just impossible to tell how big a part. -- 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 Tue Jul 22 04:18:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05415 for ; Tue, 22 Jul 2003 04:18:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19esL5-000PCO-Sp for multi6-data@psg.com; Tue, 22 Jul 2003 08:17:39 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.14) id 19esL3-000PC7-6Z for multi6@ops.ietf.org; Tue, 22 Jul 2003 08:17:37 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6M8HXCW012090; Tue, 22 Jul 2003 02:17:34 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6M8HXQ22646; Tue, 22 Jul 2003 10:17:33 +0200 (MEST) Date: Tue, 22 Jul 2003 10:15:40 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: transition to multi6 [was: Fwd: Minutes / Notes] To: "J. Noel Chiappa" Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <200307220023.h6M0NZOw008448@ginger.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-9.5 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > Actually, this leads me to think. If interoperation with unmodified hosts is > important, then all this discussion about alternative namespaces to identify > endpoints is moot. At that point, there are precisely two mechanisms > available: There is more flexibility if we e.g. introduce a new record type in the DNS for the nodes that support the new mechanism (call it an "ID", "WHO" or "WHICH" record if you'd like). A multi6-aware node will look for such record and, if found, it can do the new song and dance to get id/loc separation. If not found it falls back to looking for AAAA. Erik From owner-multi6@ops.ietf.org Tue Jul 22 04:26:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05582 for ; Tue, 22 Jul 2003 04:26:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19esSy-000Plw-Q7 for multi6-data@psg.com; Tue, 22 Jul 2003 08:25:48 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.14) id 19esSv-000PkA-78 for multi6@ops.ietf.org; Tue, 22 Jul 2003 08:25:45 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6M8P4oF014216; Tue, 22 Jul 2003 01:25:05 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6M8P3Q23106; Tue, 22 Jul 2003 10:25:04 +0200 (MEST) Date: Tue, 22 Jul 2003 10:23:11 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Source addresses and multicast (was Re: Fwd: Minutes / Notes) To: Pekka Nikander Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <3F1C2647.9060704@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > I have to admit my ignorance here. Any pointers that would allow > me to better understand what you say above? Especially, I don't > understand if the "source" address you talk about is the source > address in a packet, or the addresses (locators) of the members > of a multicast group. Steve Deerings PhD thesis explains it all :-) Google finds some easier things at: http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=reverse+path+forwarding+multicast but no good summary as far as I could tell. (I think there was an mboned intro to multicast I-D somewhere but I can't find it). In summary there is a source-rooted distribution tree which is independent of the multicast group (which is carried in the destination address field). The source rooted tree conceptually exists all the time and there is a separate tree for every source address, but the actual tree is built on demand - details depending on the multicast routing protocol which is used. The tree is then pruned based on the precence of members in the multicast group to try to avoid to deliver packets down braches where there are no members i.e. no interested receivers. The details of the tree pruning are different for different multicast routing protocols. The resulting issue for multihoming appears if a site wants to forward packets towards the rest of the internet from more than one attachment point. If the same packet ends up with different source addresses/locators when exiting through N different border routers (e.g. due to source locator rewriting by the routers) then the RPF checks will operate on two different trees and as a result each receiver will receive N copies of every packet. Erik From owner-multi6@ops.ietf.org Tue Jul 22 06:17:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08008 for ; Tue, 22 Jul 2003 06:17:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19euBI-0005ck-Gl for multi6-data@psg.com; Tue, 22 Jul 2003 10:15:40 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.14) id 19euBE-0005cS-6W for multi6@ops.ietf.org; Tue, 22 Jul 2003 10:15:36 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19euBD-0006UJ-PX for multi6@ops.ietf.org; Tue, 22 Jul 2003 03:15:35 -0700 Message-Id: <20030719133704.64c0bd08.moore@cs.utk.edu> In-Reply-To: <200307191648.h6JGmEOW024946@ginger.lcs.mit.edu> References: <200307191648.h6JGmEOW024946@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Sat, 19 Jul 2003 13:37:04 -0400 From: Keith Moore To: "J. Noel Chiappa" Cc: moore@cs.utk.edu, multi6@ops.ietf.org, jnc@ginger.lcs.mit.edu Subject: Re: Fwd: Minutes / Notes X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] ] >> This is only important if you want TCP connections to be able to ] >> survive having an incoming link fail .. This may not be an important ] >> goal ] ] > I believe that the WG has come to rough consensus that this is, in ] > fact, an important goal for us to solve. ] ] *It is architecturally crucial that the WG resolve this point.* It is essential that TCP connections be able to survive link failures. If you don't have this, you basically have to re-implement much of TCP at a higher layer. (Typically, explicit acks for application data, the ability to detect a lack of acknowledgment and to retransmit unacknowledged application data, and to gracefully handle duplicate transmissions of application data.) From owner-multi6@ops.ietf.org Tue Jul 22 06:17:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08027 for ; Tue, 22 Jul 2003 06:17:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19euBB-0005cK-Lc for multi6-data@psg.com; Tue, 22 Jul 2003 10:15:33 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.14) id 19euB1-0005bz-81 for multi6@ops.ietf.org; Tue, 22 Jul 2003 10:15:23 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19euB0-0006Tu-5B for multi6@ops.ietf.org; Tue, 22 Jul 2003 03:15:22 -0700 Message-Id: <20030719132942.7d69f3e2.moore@cs.utk.edu> In-Reply-To: <55467A3E-B9FD-11D7-8554-00039388672E@muada.com> References: <55467A3E-B9FD-11D7-8554-00039388672E@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Sat, 19 Jul 2003 13:29:42 -0400 From: Keith Moore To: Iljitsch van Beijnum Cc: moore@cs.utk.edu, Tony.Li@procket.com, multi6@ops.ietf.org Subject: Re: Minutes / Notes X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,IN_REP_TO,REFERENCES version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] ] But my personal opinion on the matter is that "substantial ] change" is a red herring. The real question is how hard it is to ] implement a solution. The substantialness or fundamentalness of the ] change has little bearing on the implementation difficulty. if by "how hard it is to implement a solution" you include the effort required to identify and upgrade all existing software that depends on existing behavior, and if you also consider the additional effort required to implement and deploy any future software that needs long-lived sessions, I might agree with you. but we must not fall into the trap of saying "here, I rewrote the kernel code to do this, and it was easy, threfore the solution is easy to implement". From owner-multi6@ops.ietf.org Tue Jul 22 06:49:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09062 for ; Tue, 22 Jul 2003 06:49:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19euh8-0007DY-28 for multi6-data@psg.com; Tue, 22 Jul 2003 10:48:34 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.14) id 19euh4-0007DM-RN for multi6@ops.ietf.org; Tue, 22 Jul 2003 10:48:30 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19euh4-0007Kt-EP for multi6@ops.ietf.org; Tue, 22 Jul 2003 03:48:30 -0700 Message-Id: <20030720210446.66f3469b.moore@cs.utk.edu> In-Reply-To: <200307202204.h6KM4fMi000906@ginger.lcs.mit.edu> References: <200307202204.h6KM4fMi000906@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Sun, 20 Jul 2003 21:04:46 -0400 From: Keith Moore To: "J. Noel Chiappa" Cc: moore@cs.utk.edu, multi6@ops.ietf.org, jnc@ginger.lcs.mit.edu Subject: Re: Fwd: Minutes / Notes X-Spam-Status: No, hits=-33.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Sun, 20 Jul 2003 18:04:41 -0400 "J. Noel Chiappa" wrote: > > From: Keith Moore > > > It is essential that TCP connections be able to survive link failures. > > If you don't have this, you basically have to re-implement much of TCP > > at a higher layer. (Typically, explicit acks for application data, the > > ability to detect a lack of acknowledgment and to retransmit > > unacknowledged application data, and to gracefully handle duplicate > > transmissions of application data.) > > Some of this you have to do anyway (e.g. "explicit acks for application > data,[and] the ability to detect a lack of acknowledgment") because the > application at the far end may consume your data (so you get an ACK from the > TCP layer), and then hang. TCP's happy, and if you're depending on TCP to > give you an error you'll be waiting forever. Mumble. For some apps, you're exactly right, and for those it's the granularity of the recovery that we're concerned about. SMTP can tolerate broken connections, but it generally does so by resending the entire message. Similarly for FTP, though some versions of FTP have a partial transfer restart capability. Other apps depend on "hanging" being a sufficiently rare condition that the app doesn't need to recover. (or that "manual recovery" is sufficient) However, we should be careful about assuming that address changes are sufficiently rare that the resulting failures of TCP connections are also inherently tolerable by these apps. (For instance, we don't expect telnet or ssh to recover from broken TCP connctions, even though failure of such a connection can be costly.) Really the question should not be whether TCP connections should be able to survive link failures - because clearly there are some kinds of link failures that cannot possibly be survived. A better question is: How long should an application be able to expect a TCP connection to last without needing to implement its own ack/retransmit/duplicate-suppression logic? My view is that a TCP connection should not become a significant additional source of failure. So it be able to last as long as its endpoints are likely to stay "up", which is on the order of months for UNIX boxes (and minutes for Windows :). Keith From owner-multi6@ops.ietf.org Tue Jul 22 06:49:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09078 for ; Tue, 22 Jul 2003 06:49:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19euh0-0007D7-AD for multi6-data@psg.com; Tue, 22 Jul 2003 10:48:26 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.14) id 19eugu-0007Cm-FY for multi6@ops.ietf.org; Tue, 22 Jul 2003 10:48:20 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19eugt-0007KZ-W8 for multi6@ops.ietf.org; Tue, 22 Jul 2003 03:48:20 -0700 Message-Id: <20030720204933.494af946.moore@cs.utk.edu> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Sun, 20 Jul 2003 20:49:33 -0400 From: Keith Moore To: "Christian Huitema" Cc: moore@cs.utk.edu, jnc@ginger.lcs.mit.edu, multi6@ops.ietf.org Subject: Re: Fwd: Minutes / Notes X-Spam-Status: No, hits=-25.8 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] > > But don't mistake these questions for the first question - of whether you > > do the separation. > > I would contend that modern applications already separate identity and > location. Take three different example, the web, SIP, and P2P file sharing > networks. In web applications, the objects are identified by an http URL; in > SIP, end points are identified by a SIP URL; in P2P networks files are > identified by their names and attributes. All of these applications treat IP > addresses strictly as locations -- some place from which you can get a web > page, to which you can send voice packets, from which you can get a slice of > a file. The specific IP addresses vary over time, depending upon load > balancing in web farms, transient registrations in SIP, or which of the file > publishers happens to be on-line with P2P file sharing networks. P2P and the > web, combined, represent the bulk of current Internet traffic. The examples you cited have identifiers for resource names that are in a separate space from that used for identifiers for locations. This isn't at all the same thing as separating host identity from host location. Neither the web nor SIP do this, and the p2p file sharing networks with which I'm familiar don't really do this either (though some have a hack that attempts to tolerates the endpoints having different views of IP addresses). Offhand I don't recall that either the web or SIP need to identify hosts, as opposed to resources, so it seems that both of them are irrelevant as examples. So your conclusions do not follow. Having helped write an application that does this, it's a major pain to expect apps to define their own set of identities for hosts. Unfortunately, neither DNS names (as deployed) nor IP addresses (as deployed) are up to the job - both are ambiguous, both are often only usable from limited realms, DNS names are slow and too-often unreliable. From owner-multi6@ops.ietf.org Tue Jul 22 06:50:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09106 for ; Tue, 22 Jul 2003 06:50:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eugs-0007CI-9Q for multi6-data@psg.com; Tue, 22 Jul 2003 10:48:18 +0000 Received: from [206.197.161.140] (helo=uillean.fuaim.com) by psg.com with esmtp (Exim 4.14) id 19eugg-0007Au-9R for multi6@ops.ietf.org; Tue, 22 Jul 2003 10:48:06 +0000 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h6MAl5N01572; Tue, 22 Jul 2003 03:47:05 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6c-69.chvlva.adelphia.net [67.20.163.69]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h6MBUlp0017185 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 22 Jul 2003 04:30:50 -0700 Message-ID: <3F1D165E.8030006@innovationslab.net> Date: Tue, 22 Jul 2003 06:47:58 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Pekka Nikander , multi6@ops.ietf.org Subject: Re: Source addresses and multicast (was Re: Fwd: Minutes / Notes) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>I have to admit my ignorance here. Any pointers that would allow >>me to better understand what you say above? Especially, I don't >>understand if the "source" address you talk about is the source >>address in a packet, or the addresses (locators) of the members >>of a multicast group. > > > Steve Deerings PhD thesis explains it all :-) > Google finds some easier things at: > http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=reverse+path+forwarding+multicast > but no good summary as far as I could tell. > (I think there was an mboned intro to multicast I-D somewhere but I can't find > it). > > In summary there is a source-rooted distribution tree which is independent > of the multicast group (which is carried in the destination address field). > The source rooted tree conceptually exists all the time and there is > a separate tree for every source address, but the actual tree is built > on demand - details depending on the multicast routing protocol which is > used. > > The tree is then pruned based on the precence of members in the multicast group > to try to avoid to deliver packets down braches where there are no members > i.e. no interested receivers. The details of the tree pruning are different > for different multicast routing protocols. > > The resulting issue for multihoming appears if a site wants > to forward packets towards the rest of the internet from more than > one attachment point. > If the same packet ends up with different source addresses/locators > when exiting through N different border routers (e.g. due to source > locator rewriting by the routers) then the RPF checks will > operate on two different trees and as a result each receiver will receive > N copies of every packet. Well, some of this depends on the multicast routing protocol in use and the implementation. Your description is much closer to what dense mode protocols do for multicast forwarding (DVMRP and PIM-DM). PIM-SM will build the distribution tree prior to data flowing. When PIM-SM builds source-rooted trees, the RPF check will be built on the Locator value, not the ID since the RPF is a topological check. The issue of multiple trees due to multi-homing can be modeled in much the same way that multicast is implemented over load-balancing links. That is, a single forwarding entry is instantiated and "locked" to a path. Of course, you would probably lose forwarding state during an outage. With SSM, the forwarding entry will be tied to specific source address. In SSM and multi-homing this may have to be the ID rather than the Locator, even though the Locator is needed for the RPF check. Regards, Brian From owner-multi6@ops.ietf.org Wed Jul 23 13:50:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21192 for ; Wed, 23 Jul 2003 13:50:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fNhb-000Dz9-AH for multi6-data@psg.com; Wed, 23 Jul 2003 17:46:59 +0000 Received: from [195.43.225.73] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.14) id 19fNhY-000Dyn-1v for multi6@ops.ietf.org; Wed, 23 Jul 2003 17:46:56 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6NHkrFJ003862 for ; Wed, 23 Jul 2003 19:46:56 +0200 (CEST) Date: Wed, 23 Jul 2003 19:46:48 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=fixed Subject: Broken mail-server From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-14.0 required=5.0 tests=BAYES_10,PGP_SIGNATURE,UPPERCASE_25_50,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If anyone tried to send me comment on the minutes on Monday that most likely failed as my mail-server was broken. If there are now further comments within 24h I will send the minutes to the IETF secretariat. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPx7KC6arNKXTPFCVEQJuGwCg4zleSrbuUN6yynDIZ417SJAbdkEAoIlR SYkUGMmBzPD3KDYKIsgST8yz =q+16 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Jul 23 14:34:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22693 for ; Wed, 23 Jul 2003 14:34:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fOQJ-000Gpm-HN for multi6-data@psg.com; Wed, 23 Jul 2003 18:33:11 +0000 Received: from [209.226.175.187] (helo=tomts24-srv.bellnexxia.net) by psg.com with esmtp (Exim 4.14) id 19fOQG-000GpZ-O9 for multi6@ops.ietf.org; Wed, 23 Jul 2003 18:33:08 +0000 Received: from yahoo.com ([65.93.188.244]) by tomts24-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030723183307.VPIW27964.tomts24-srv.bellnexxia.net@yahoo.com>; Wed, 23 Jul 2003 14:33:07 -0400 Date: Wed, 23 Jul 2003 14:33:06 -0400 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Christian Huitema" From: S Woodside In-Reply-To: Message-Id: <1A580776-BD3C-11D7-B88E-000A9573F104@yahoo.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-22.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,FORGED_YAHOO_RCVD,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_FAKE_HELO_DOTCOM,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It's worth noting though that this is what these p2p applications do, it's the core of their development. one could equally argue that anykind of ad-hoc mesh protocol work could learn a lot from the p2p apps. it's a long way from that to expecting average program to do the same things. simon On Saturday, July 19, 2003, at 04:06 PM, Christian Huitema wrote: > I heard many say during the multi6 debate that applications cannot > possibly handle multiple addresses well. To disprove that, I suggest > you take a look at the variations of "swarmcast" implemented by P2P > systems such as Kazaa or E-Donkey. These systems are about exchanging > files, so they have their own identification system -- file names. The > naming system can resolve file names to multiple locations of a file. > The transfer system then asks slices of the file from a set of more or > less randomly chosen locations. It automatically adjust to topology > by asking more from those locations that serve faster. And it > automatically compensate connection losses by just repeating the slice > request, or a fraction of it, to some other nodes. Such a system would > handle multi-addressing beautifully. -- www.simonwoodside.com -- 99% Devil, 1% Angel From owner-multi6@ops.ietf.org Wed Jul 23 15:44:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28639 for ; Wed, 23 Jul 2003 15:44:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fPWR-000Kyz-PP for multi6-data@psg.com; Wed, 23 Jul 2003 19:43:35 +0000 Received: from [160.36.58.43] (helo=astro.cs.utk.edu) by psg.com with esmtp (Exim 4.14) id 19fPWO-000Kyj-L4 for multi6@ops.ietf.org; Wed, 23 Jul 2003 19:43:32 +0000 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6NJfqJ19974; Wed, 23 Jul 2003 15:41:53 -0400 (EDT) Date: Wed, 23 Jul 2003 15:41:52 -0400 From: Keith Moore To: S Woodside Cc: moore@cs.utk.edu, huitema@windows.microsoft.com, multi6@ops.ietf.org Subject: Re: Minutes / Notes Message-Id: <20030723154152.656cffd3.moore@cs.utk.edu> In-Reply-To: <1A580776-BD3C-11D7-B88E-000A9573F104@yahoo.com> References: <1A580776-BD3C-11D7-B88E-000A9573F104@yahoo.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit many p2p apps do their own routing because they are forced to do so, not because this is a desirable or acceptable burden to impose on applications. also, what works acceptably well in a system to transfer widely-replicated files does not necessarily work well in a system where host identity is important. Keith > It's worth noting though that this is what these p2p applications do, > it's the core of their development. one could equally argue that > anykind of ad-hoc mesh protocol work could learn a lot from the p2p > apps. it's a long way from that to expecting average program to do the > same things. > > > I heard many say during the multi6 debate that applications cannot > > possibly handle multiple addresses well. To disprove that, I suggest > > you take a look at the variations of "swarmcast" implemented by P2P > > systems such as Kazaa or E-Donkey. These systems are about > > exchanging files, so they have their own identification system -- > > file names. The naming system can resolve file names to multiple > > locations of a file. The transfer system then asks slices of the > > file from a set of more or less randomly chosen locations. It > > automatically adjust to topology by asking more from those locations > > that serve faster. And it automatically compensate connection losses > > by just repeating the slice request, or a fraction of it, to some > > other nodes. Such a system would handle multi-addressing > > beautifully. From owner-multi6@ops.ietf.org Wed Jul 23 16:17:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01062 for ; Wed, 23 Jul 2003 16:17:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fQ1k-000MtJ-VS for multi6-data@psg.com; Wed, 23 Jul 2003 20:15:56 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19fQ1i-000Msi-EP for multi6@ops.ietf.org; Wed, 23 Jul 2003 20:15:54 +0000 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 23 Jul 2003 13:15:41 -0700 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 23 Jul 2003 13:15:41 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 23 Jul 2003 13:15:41 -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); Wed, 23 Jul 2003 13:15:40 -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.0); Wed, 23 Jul 2003 13:15:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: Minutes / Notes Date: Wed, 23 Jul 2003 13:13:14 -0700 Message-ID: Thread-Topic: Minutes / Notes Thread-Index: AcNRUo3RKGacCOyDSAqYCJK5Je2dKwABAjjA From: "Christian Huitema" To: "Keith Moore" , "S Woodside" Cc: X-OriginalArrivalTime: 23 Jul 2003 20:15:41.0967 (UTC) FILETIME=[30D361F0:01C35157] X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > many p2p apps do their own routing because they are forced to do so, > not because this is a desirable or acceptable burden to impose on > applications. also, what works acceptably well in a system to > transfer widely-replicated files does not necessarily work well in a > system where host identity is important. There are pretty few systems were "host identity" is what really matters; in most cases, you want something like domain or user identity. For example, "www.google.com" is not exactly 1 single host.=20 -- Christian Huitema From owner-multi6@ops.ietf.org Wed Jul 23 16:23:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01313 for ; Wed, 23 Jul 2003 16:22:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fQ89-000NEr-Px for multi6-data@psg.com; Wed, 23 Jul 2003 20:22:33 +0000 Received: from [160.36.58.43] (helo=astro.cs.utk.edu) by psg.com with esmtp (Exim 4.14) id 19fQ87-000NEf-5n for multi6@ops.ietf.org; Wed, 23 Jul 2003 20:22:31 +0000 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6NKLBJ20093; Wed, 23 Jul 2003 16:21:12 -0400 (EDT) Date: Wed, 23 Jul 2003 16:21:11 -0400 From: Keith Moore To: "Christian Huitema" Cc: moore@cs.utk.edu, sbwoodside@yahoo.com, multi6@ops.ietf.org Subject: Re: Minutes / Notes Message-Id: <20030723162111.57a47ea7.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-26.6 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > many p2p apps do their own routing because they are forced to do so, > > not because this is a desirable or acceptable burden to impose on > > applications. also, what works acceptably well in a system to > > transfer widely-replicated files does not necessarily work well in a > > system where host identity is important. > > There are pretty few systems were "host identity" is what really > matters; in most cases, you want something like domain or user > identity. For example, "www.google.com" is not exactly 1 single host. I don't know any way to enumerate those systems, but there's an important class of systems for which this does not apply - the systems for which some amount of required data lives in the private memory of some process which lives on a particular host (NOT in a domain). This applies to most of the distributed computing systems I know about. And as long as hosts don't make their memory directly accessible by outside processes, such systems will quite reasonably exist. Of course, as long if you keep using the web as an example of a typical distributed app, you're going to miss those important counterexamples. Keith From owner-multi6@ops.ietf.org Wed Jul 23 17:30:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03616 for ; Wed, 23 Jul 2003 17:30:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fRAC-0000yz-Ej for multi6-data@psg.com; Wed, 23 Jul 2003 21:28:44 +0000 Received: from [130.242.94.170] (helo=slimsixten.besserwisser.org ident=root) by psg.com with esmtp (Exim 4.14) id 19fRA8-0000xj-NQ for multi6@ops.ietf.org; Wed, 23 Jul 2003 21:28:40 +0000 Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.6) with ESMTP id h6NLSmlE004418 for ; Wed, 23 Jul 2003 23:28:50 +0200 (CEST) Date: Wed, 23 Jul 2003 12:48:28 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: multi6@ops.ietf.org Subject: Re: Fwd: Minutes / Notes Message-ID: <193530000.1058957308@localhost> In-Reply-To: <20030719133704.64c0bd08.moore@cs.utk.edu> References: <200307191648.h6JGmEOW024946@ginger.lcs.mit.edu> <20030719133704.64c0bd08.moore@cs.utk.edu> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========2151587794==========" X-Spam-Status: No, hits=-31.4 required=5.0 tests=BAYES_10,DATE_IN_PAST_06_12,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk --==========2151587794========== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Saturday, July 19, 2003 13:37:04 -0400 Keith Moore wrote: > It is essential that TCP connections be able to survive link failures. > If you don't have this, you basically have to re-implement much of TCP at > a higher layer. (Typically, explicit acks for application data, the > ability to detect a lack of acknowledgment and to retransmit > unacknowledged application data, and to gracefully handle duplicate > transmissions of application data.) I agree -- this is important, and if altered would break lots of things.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========2151587794========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE/Hmf902/pMZDM1cURAlM0AJkBxyMtRlcjf7ZhCZws6qIPLq3gRACeLrtZ DYH8Q3ubnIUJQht3gPWWWCY= =yTqn -----END PGP SIGNATURE----- --==========2151587794==========-- From owner-multi6@ops.ietf.org Wed Jul 23 19:47:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07989 for ; Wed, 23 Jul 2003 19:47:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fTHy-0008rp-Sp for multi6-data@psg.com; Wed, 23 Jul 2003 23:44:54 +0000 Received: from [209.226.175.187] (helo=tomts24-srv.bellnexxia.net) by psg.com with esmtp (Exim 4.14) id 19fTHT-0008oi-5u for multi6@ops.ietf.org; Wed, 23 Jul 2003 23:44:23 +0000 Received: from yahoo.com ([65.93.186.133]) by tomts24-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030723234421.FYNL27964.tomts24-srv.bellnexxia.net@yahoo.com>; Wed, 23 Jul 2003 19:44:21 -0400 Date: Wed, 23 Jul 2003 19:44:19 -0400 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Tony Li" From: S Woodside In-Reply-To: Message-Id: <9450B7B8-BD67-11D7-B88E-000A9573F104@yahoo.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-22.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,FORGED_YAHOO_RCVD,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_FAKE_HELO_DOTCOM,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sunday, July 20, 2003, at 11:00 PM, Tony Li wrote: > The advantages go to those hosts that are multi-homed, and that > has typically been about 10% of the sites out there. [Aside: > I suspect that this will grow as the Internet gets 'bushier'.] > The advantages also go to their correspondent hosts. > It will IMO also grow if multihoming becomes easier ;-) With wireless networks it is much easier to multihome at the PHYSICAL layer than it was a few years ago. simon From owner-multi6@ops.ietf.org Wed Jul 23 19:54:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08084 for ; Wed, 23 Jul 2003 19:54:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fTQg-0009Wg-Pl for multi6-data@psg.com; Wed, 23 Jul 2003 23:53:54 +0000 Received: from [209.226.175.187] (helo=tomts24-srv.bellnexxia.net) by psg.com with esmtp (Exim 4.14) id 19fTQe-0009WU-De for multi6@ops.ietf.org; Wed, 23 Jul 2003 23:53:52 +0000 Received: from yahoo.com ([65.93.186.133]) by tomts24-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030723235351.GDKV27964.tomts24-srv.bellnexxia.net@yahoo.com>; Wed, 23 Jul 2003 19:53:51 -0400 Date: Wed, 23 Jul 2003 19:53:49 -0400 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: Pekka Savola From: S Woodside In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-22.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,FORGED_YAHOO_RCVD,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_FAKE_HELO_DOTCOM,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, July 21, 2003, at 02:53 AM, Pekka Savola wrote: > I don't really think the "site-exit routers approach" scales for very > small sites ("home networks"). > > But then again, my perception is that very small sites can easily live > without connection surviability. These aren't really mission-critical > systems, systems where network downtime could cost e.g. 1000$ a minute. > > The ability to start new connections using the other connectivity is > probably good enough for most folks. > Pekka, That seems reasonable, another dimension to add to the taxonomy of multihoming users? I would agree that the smallest sites would think connection survivability less important. simon -- www.simonwoodside.com -- 99% Devil, 1% Angel From owner-multi6@ops.ietf.org Wed Jul 23 21:17:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09400 for ; Wed, 23 Jul 2003 21:17:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fUib-000DfA-UW for multi6-data@psg.com; Thu, 24 Jul 2003 01:16:29 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.14) id 19fUiX-000DeL-JN for multi6@ops.ietf.org; Thu, 24 Jul 2003 01:16:25 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 93F2334435; Wed, 23 Jul 2003 18:15:36 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6O1FtYB004232; Wed, 23 Jul 2003 18:15:55 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Minutes / Notes Date: Wed, 23 Jul 2003 18:15:55 -0700 Message-ID: Thread-Topic: Minutes / Notes Thread-Index: AcNRdFuXMhhc7iRETTy8Uf3/boFTDwADJVDw From: "Tony Li" To: "S Woodside" Cc: X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable | It will IMO also grow if multihoming becomes easier ;-)=20 | With wireless=20 | networks it is much easier to multihome at the PHYSICAL=20 | layer than it=20 | was a few years ago. Amen. I'm 'accidentally' multi-homed at my house because my neighbor and I both connected our cable modems to 802.11b nodes. Fortunately, we have different cable providers... Tony From owner-multi6@ops.ietf.org Wed Jul 23 22:30:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10642 for ; Wed, 23 Jul 2003 22:30:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fVr2-000H0D-FU for multi6-data@psg.com; Thu, 24 Jul 2003 02:29:16 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fVqe-000GzW-L8 for multi6@ops.ietf.org; Thu, 24 Jul 2003 02:28:52 +0000 From: Masataka Ohta Message-Id: <200307240217.LAA03416@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA03416; Thu, 24 Jul 2003 11:17:30 +0900 Subject: Re: Fwd: Minutes / Notes In-Reply-To: <200307191715.h6JHFTd2025078@ginger.lcs.mit.edu> from "J. Noel Chiappa" at "Jul 19, 2003 01:15:29 pm" To: "J. Noel Chiappa" Date: Thu, 24 Jul 2003 11:17:28 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Noel; > Or suppose you go with 8+8, or a solution where the identity is not carried > in every packet. If you want to change the location, there are a couple of > packets of negotiation to change the binding and then you're done. Basically > all packets are as efficient as the less-capable case. By definition, lower 8 bytes of 8+8 address is ID that 8+8 carries the identity in every packet. > If you want to change the location, there are a couple of > packets of negotiation to change the binding and then you're done. It means not all the locators are carried in every packet, which is of course even with mobility based ones or 16+16. Masataka Ohta From owner-multi6@ops.ietf.org Wed Jul 23 23:09:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11171 for ; Wed, 23 Jul 2003 23:09:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fWTP-000Iwp-Ph for multi6-data@psg.com; Thu, 24 Jul 2003 03:08:55 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fWTN-000Iwc-D9 for multi6@ops.ietf.org; Thu, 24 Jul 2003 03:08:53 +0000 From: Masataka Ohta Message-Id: <200307240257.LAA03578@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA03578; Thu, 24 Jul 2003 11:56:50 +0859 Subject: Re: Fwd: Minutes / Notes In-Reply-To: from marcelo bagnulo at "Jul 20, 2003 05:41:59 pm" To: marcelo bagnulo Date: Thu, 24 Jul 2003 11:56:50 +0859 () CC: "J. Noel Chiappa" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Marcelo; > > There is also the issue of whether or not you want to carry both > > the location > > and identity in all packets. You more or less have to have the location, > > otherwise the packet can't get there. Whether or not you carry > > the identity > > as well is an architectural/engineering question. > > > As it was mentioned in the meeting, information contained in packets binding > locators to identifiers can not be trusted (unless it is secured with > additional tools), And it was an error corrected at the meeting. Binding between locators and identifiers in single packets have just enough security. Masataka Ohta From owner-multi6@ops.ietf.org Wed Jul 23 23:09:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11189 for ; Wed, 23 Jul 2003 23:09:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fWTG-000IwY-A8 for multi6-data@psg.com; Thu, 24 Jul 2003 03:08:46 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fWTD-000IvM-51 for multi6@ops.ietf.org; Thu, 24 Jul 2003 03:08:43 +0000 From: Masataka Ohta Message-Id: <200307240252.LAA03567@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA03567; Thu, 24 Jul 2003 11:52:29 +0900 Subject: Re: Source address selection in IPv6 multihomed multi-addressed sites In-Reply-To: <6E592DA4-BAB3-11D7-8554-00039388672E@muada.com> from Iljitsch van Beijnum at "Jul 20, 2003 03:09:44 pm" To: Iljitsch van Beijnum Date: Thu, 24 Jul 2003 11:52:28 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > > However, to enable source address filtering to discard packets with > > source addresses not belonging to an ISP, it is useful to enable a > > host, not some intelligent intermediate router, select a source > > address compatible with an outgoing ISP. For that purpose, intra > > domain routing protocols or something like that should maintain > > routing table entries with not only preference values of an external > > routes, but also proper prefixes to be selected for source > > addresses, > > if the entries are chosen by a host. > > > It should be noted that it is already doable with the current OSPF > > spec. > > Hm, how would that work? In BGP you could see the next hop AS number > and map this to a source address, And the information is carried by IGP as has been stated in my draft. > but in OSPF there is no obvious way > to do this. (Although I'm sure a non-obvious way can be created.) You should check the format of AS-external-LSAs, of, say, RFC2740, where there is a place to hold addresses of outgoing routers. > However, I certainly wouldn't want hosts to interact with OSPF as this > is a somewhat fragile protocol. In RIP you can simply ignore what hosts > have to say and in BGP you can filter it, but in OSPF as-is you can > only hope the host don't send any information that screws up the > routing table. The paragraph above contains so much errors to worth commenting. > And then there is still the problem of how useful this information is. > Even today with BGP is is fairly common that BGP selects a very bad > route You can use whatever EGP you like, though BGP practically is the only solution. > What BGP doesn't know is that the > interconnect between B and C is 500 km away while the interconnect > between D and E is on another continent. Relying on ASPATHLEN does not address the issue. On the other hand, BGP administrators know that the interconnect between B and C is 500 km away while the interconnect between D and E is on another continent. However, BGP administrators feel difficulty to grasp connections between neighbor ASes, if there are so many neighbor ASes. > Obviously this problem is only > going to get worse as the routing table becomes smaller. That's why I > think that there will always be upward pressure for the routing table > size. The smaller routing table allows more policy based control, not blindly relying on ASPATHLEN. Masataka Ohta From owner-multi6@ops.ietf.org Wed Jul 23 23:29:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11467 for ; Wed, 23 Jul 2003 23:29:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fWmz-000Jzr-5i for multi6-data@psg.com; Thu, 24 Jul 2003 03:29:09 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fWmv-000JzK-UL for multi6@ops.ietf.org; Thu, 24 Jul 2003 03:29:06 +0000 From: Masataka Ohta Message-Id: <200307240320.MAA03808@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA03808; Thu, 24 Jul 2003 12:20:18 +0900 Subject: Re: Fwd: Minutes / Notes In-Reply-To: <3F1ADB13.2010809@nomadiclab.com> from Pekka Nikander at "Jul 20, 2003 09:10:27 pm" To: Pekka Nikander Date: Thu, 24 Jul 2003 12:20:15 +0859 () CC: marcelo bagnulo , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka; > > For the source endpoint information, i am not sure > > I think that carrying the source identifier would make more sense, since it > > identifies the other endd of the communication. > > Carrying a source identifier is harmful. For our argument, see > > Catharina Candolin and Pekka Nikander, "IPv6 Source Addresses Considered > Harmful," in Hanne Riis Nielson (ed.), Proceedings of NordSec 2001, > Sixth Nordoc Workshop on Secure IT Systems, November 1-2, Lyngby, > Denmark, Technical Report IMM-TR-2001-14, pp. 54-68, Technical > University of Denmark, November 2001. > > http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf You forgot the fact that the Internet is a public network. Masataka Ohta From owner-multi6@ops.ietf.org Wed Jul 23 23:39:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11616 for ; Wed, 23 Jul 2003 23:39:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fWwW-000KYA-4B for multi6-data@psg.com; Thu, 24 Jul 2003 03:39:00 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fWwT-000KXq-LQ for multi6@ops.ietf.org; Thu, 24 Jul 2003 03:38:57 +0000 From: Masataka Ohta Message-Id: <200307240332.MAA03849@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA03849; Thu, 24 Jul 2003 12:31:51 +0859 Subject: Re: Fwd: Minutes / Notes In-Reply-To: from Christian Huitema at "Jul 20, 2003 04:41:30 pm" To: Christian Huitema Date: Thu, 24 Jul 2003 12:31:51 +0859 () CC: "J. Noel Chiappa" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-11.3 required=5.0 tests=BAYES_10,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk [Charset iso-8859-1 unsupported, filtering to ASCII...] > > But don't mistake these questions for the first question - of whether you do > > the separation. > > I would contend that modern applications already separate identity and location. Of resources or hosts? > Take three different example, the web, SIP, and P2P file sharing networks. In web applications, the objects are identified by an http URL; > in SIP, end points are identified by a SIP URL; > in P2P networks files are identified by their names and attributes. URL locates, not identifies, resource, not host. > All of these applications treat IP addresses strictly as locations Wrong. With URL, you can identify resource on a host, only if you can identify the host. If a host holding a resource is, at the same location, replaced by another host holding different resource, URL now points to resource with different identity. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jul 24 00:19:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12274 for ; Thu, 24 Jul 2003 00:19:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fXZF-000MYw-Ng for multi6-data@psg.com; Thu, 24 Jul 2003 04:19:01 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fXZD-000MYj-D0 for multi6@ops.ietf.org; Thu, 24 Jul 2003 04:18:59 +0000 From: Masataka Ohta Message-Id: <200307240407.NAA04148@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id NAA04148; Thu, 24 Jul 2003 13:07:29 +0900 Subject: Re: Minutes / Notes In-Reply-To: <3F1C24BF.1060306@nomadiclab.com> from Pekka Nikander at "Jul 21, 2003 08:37:03 pm" To: Pekka Nikander Date: Thu, 24 Jul 2003 13:07:27 +0859 () CC: Tony Li , Erik Nordmark , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka; > The important point is, however, that if the id/loc separation > is done, the source address is not needed by the end-hosts any > more. It is needed in the very first packet flowing in a direction, > and perhaps in the second one, until the id->loc state is verified > and established, but not after that. The Internet is connectionless. TCP is not IP, the Internet Protocol. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jul 24 00:26:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12816 for ; Thu, 24 Jul 2003 00:26:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fXgc-000Mvq-9K for multi6-data@psg.com; Thu, 24 Jul 2003 04:26:38 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19fXgX-000MvO-Vj for multi6@ops.ietf.org; Thu, 24 Jul 2003 04:26:34 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 736C51C; Thu, 24 Jul 2003 07:35:40 +0300 (EEST) Message-ID: <3F1F5FDA.6070005@nomadiclab.com> Date: Thu, 24 Jul 2003 07:26:02 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masataka Ohta Cc: marcelo bagnulo , "J. Noel Chiappa" , multi6@ops.ietf.org Subject: Re: Fwd: Minutes / Notes References: <200307240257.LAA03578@necom830.hpcl.titech.ac.jp> In-Reply-To: <200307240257.LAA03578@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka Ohta wrote: > Binding between locators and identifiers in single packets have > just enough security. Strongly disagree. See the flooding attacks in http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro-sec-01.txt They do not, as such, directly apply to multi-homing, but you can fairly easily find out variants that do. --Pekka Nikander From owner-multi6@ops.ietf.org Thu Jul 24 00:29:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12867 for ; Thu, 24 Jul 2003 00:29:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fXjV-000N4J-Ra for multi6-data@psg.com; Thu, 24 Jul 2003 04:29:37 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19fXjT-000N3Q-Rt for multi6@ops.ietf.org; Thu, 24 Jul 2003 04:29:36 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 084B11C; Thu, 24 Jul 2003 07:38:43 +0300 (EEST) Message-ID: <3F1F608F.8030809@nomadiclab.com> Date: Thu, 24 Jul 2003 07:29:03 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masataka Ohta Cc: Tony Li , Erik Nordmark , multi6@ops.ietf.org Subject: Re: Minutes / Notes References: <200307240407.NAA04148@necom830.hpcl.titech.ac.jp> In-Reply-To: <200307240407.NAA04148@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-35.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka Ohta wrote: >>The important point is, however, that if the id/loc separation >>is done, the source address is not needed by the end-hosts any >>more. It is needed in the very first packet flowing in a direction, >>and perhaps in the second one, until the id->loc state is verified >>and established, but not after that. > > The Internet is connectionless. > > TCP is not IP, the Internet Protocol. < Id -> locator > mapping / binding / whatever is state. --Pekka Nikander From owner-multi6@ops.ietf.org Thu Jul 24 00:50:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13134 for ; Thu, 24 Jul 2003 00:50:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fY26-000O8x-Of for multi6-data@psg.com; Thu, 24 Jul 2003 04:48:50 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fY23-000O8Q-Ff for multi6@ops.ietf.org; Thu, 24 Jul 2003 04:48:47 +0000 From: Masataka Ohta Message-Id: <200307240437.NAA04361@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id NAA04361; Thu, 24 Jul 2003 13:37:12 +0900 Subject: Re: Fwd: Minutes / Notes In-Reply-To: <3F1F5FDA.6070005@nomadiclab.com> from Pekka Nikander at "Jul 24, 2003 07:26:02 am" To: Pekka Nikander Date: Thu, 24 Jul 2003 13:37:11 +0859 () CC: marcelo bagnulo , "J. Noel Chiappa" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-11.9 required=5.0 tests=BAYES_10,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka; > > Binding between locators and identifiers in single packets have > > just enough security. It should also be noted that binding between locators and identifiers in single DNS reply packets have just enough security. > Strongly disagree. See the flooding attacks in > http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro-sec-01.txt > > They do not, as such, directly apply to multi-homing, Notification of locator changes, of course, needs its own security, which does not apply to multi-homing issue here, not even indirectly. > but you can fairly easily find out variants that do. Wrong. The variant (or a simple case) is an issue to be addressed by return routability and/or DNS reverse/forward mapping just as current IPv4 or 6. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jul 24 02:40:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26573 for ; Thu, 24 Jul 2003 02:40:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fZkg-0003A8-MT for multi6-data@psg.com; Thu, 24 Jul 2003 06:38:58 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fZke-00039v-8K for multi6@ops.ietf.org; Thu, 24 Jul 2003 06:38:56 +0000 From: Masataka Ohta Message-Id: <200307240626.PAA04677@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA04677; Thu, 24 Jul 2003 15:26:18 +0900 Subject: Re: Minutes / Notes In-Reply-To: <3F1F608F.8030809@nomadiclab.com> from Pekka Nikander at "Jul 24, 2003 07:29:03 am" To: Pekka Nikander Date: Thu, 24 Jul 2003 15:26:18 +0859 () CC: Tony Li , Erik Nordmark , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka; > >>The important point is, however, that if the id/loc separation > >>is done, the source address is not needed by the end-hosts any > >>more. It is needed in the very first packet flowing in a direction, > >>and perhaps in the second one, until the id->loc state is verified > >>and established, but not after that. > > > > The Internet is connectionless. > > > > TCP is not IP, the Internet Protocol. > > < Id -> locator > mapping / binding / whatever is state. Huh? State? IP layer does have certain state such as that for routing table, which does not make it connection oriented. Of course, there certainly is state of a connection, which MUST be located at the transport layer or above, which is why destination locator MUST be chosen by the transport layer or above. The Internet is connectionless. So is IP. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jul 24 03:39:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27406 for ; Thu, 24 Jul 2003 03:39:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fag2-00060m-Su for multi6-data@psg.com; Thu, 24 Jul 2003 07:38:14 +0000 Received: from [194.196.100.238] (helo=d12lmsgate-5.de.ibm.com) by psg.com with esmtp (Exim 4.14) id 19fag0-0005yf-EO for multi6@ops.ietf.org; Thu, 24 Jul 2003 07:38:12 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6O7bFu5048310; Thu, 24 Jul 2003 09:37:16 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6O7bEcH214886; Thu, 24 Jul 2003 09:37:15 +0200 Received: from hursley.ibm.com (dhcp22-107.zurich.ibm.com [9.4.22.107]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA17834; Thu, 24 Jul 2003 09:37:13 +0200 Message-ID: <3F1F8CAD.A09432D2@hursley.ibm.com> Date: Thu, 24 Jul 2003 09:37:17 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Pekka Nikander , multi6@ops.ietf.org CC: Masataka Ohta Subject: Re: Minutes / Notes References: <200307240407.NAA04148@necom830.hpcl.titech.ac.jp> <3F1F608F.8030809@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > > Masataka Ohta wrote: > >>The important point is, however, that if the id/loc separation > >>is done, the source address is not needed by the end-hosts any > >>more. It is needed in the very first packet flowing in a direction, > >>and perhaps in the second one, until the id->loc state is verified > >>and established, but not after that. > > > > The Internet is connectionless. > > > > TCP is not IP, the Internet Protocol. > > < Id -> locator > mapping / binding / whatever is state. It's state in the same way that the routing tables are state - i.e. in general transport and applications have been taught to ignore it, and it gets recreated by magic when it gets destroyed. But this WG has to worry about the magic. Brian From owner-multi6@ops.ietf.org Thu Jul 24 03:41:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27454 for ; Thu, 24 Jul 2003 03:41:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fai1-0006Aq-Q0 for multi6-data@psg.com; Thu, 24 Jul 2003 07:40:17 +0000 Received: from [194.196.100.234] (helo=d12lmsgate.de.ibm.com) by psg.com with esmtp (Exim 4.14) id 19fahz-00064w-2c for multi6@ops.ietf.org; Thu, 24 Jul 2003 07:40:15 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6O7dco1234376 for ; Thu, 24 Jul 2003 09:39:41 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6O7dccH265908 for ; Thu, 24 Jul 2003 09:39:38 +0200 Received: from hursley.ibm.com (dhcp22-107.zurich.ibm.com [9.4.22.107]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA25844 for ; Thu, 24 Jul 2003 09:39:37 +0200 Message-ID: <3F1F8D3D.6A15AC16@hursley.ibm.com> Date: Thu, 24 Jul 2003 09:39:41 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Minutes / Notes References: <20030723162111.57a47ea7.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: > > > > many p2p apps do their own routing because they are forced to do so, > > > not because this is a desirable or acceptable burden to impose on > > > applications. also, what works acceptably well in a system to > > > transfer widely-replicated files does not necessarily work well in a > > > system where host identity is important. > > > > There are pretty few systems were "host identity" is what really > > matters; in most cases, you want something like domain or user > > identity. For example, "www.google.com" is not exactly 1 single host. > > I don't know any way to enumerate those systems, but there's an > important class of systems for which this does not apply - the systems > for which some amount of required data lives in the private memory of > some process which lives on a particular host (NOT in a domain). This > applies to most of the distributed computing systems I know about. And > as long as hosts don't make their memory directly accessible by outside > processes, such systems will quite reasonably exist. But increasingly, they are based on virtualized IP addresses and include provision for application failover to another server when the original server fails. So the semantics of identifiers are getting more subtle. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NOTE: My email will soon change to brc@zurich.ibm.com Try that if you get failure messages. From owner-multi6@ops.ietf.org Thu Jul 24 04:59:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29715 for ; Thu, 24 Jul 2003 04:59:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fbw2-000APZ-I9 for multi6-data@psg.com; Thu, 24 Jul 2003 08:58:50 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fbvz-000AOd-7f for multi6@ops.ietf.org; Thu, 24 Jul 2003 08:58:47 +0000 From: Masataka Ohta Message-Id: <200307240844.RAA05300@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA05300; Thu, 24 Jul 2003 17:43:52 +0859 Subject: Re: Minutes / Notes In-Reply-To: from Iljitsch van Beijnum at "Jul 20, 2003 03:11:41 pm" To: Iljitsch van Beijnum Date: Thu, 24 Jul 2003 17:43:52 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > >> I have a few technical (not editorial) comments on some points in the > >> minutes, > >> which are therefore of general interest... > > > A problem is that the minutes lacks discussioin on so many errors of > > Iljitsch's proposal that yo are repeating my points at the meeting > > Well, let's hear it then. What are those errors? 1) On slide of "loc/id separation", the mapping from FQDN should not be FQDN -> ID -> Locators but should be FQDN -> (ID, Locators) to avoid extra mapping and possible security problem. 2) On slide of pros and cons of "small", all the "cons" are wrong as follows. 2.1) Work with unaggregatable MAC namespace or break autoconfiguration Structured ID can be autoconfigured by DHCP. 2.2) Can't trust incoming id-loc association Association between an ID and locators is secure if they are contained in a single packet. 2.3) If not break, certainly bend transports With LIN6 trick, API for TCP stays same. 2.4) Changes to both hosts and routers There is no changes to routers There are other errors I didn't bothered to correct. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jul 24 05:01:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29793 for ; Thu, 24 Jul 2003 05:01:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fby5-000Abl-7g for multi6-data@psg.com; Thu, 24 Jul 2003 09:00:57 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fby2-000AbX-GO for multi6@ops.ietf.org; Thu, 24 Jul 2003 09:00:54 +0000 From: Masataka Ohta Message-Id: <200307240854.RAA05382@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA05382; Thu, 24 Jul 2003 17:54:04 +0900 Subject: International site? In-Reply-To: from Kurt Erik Lindqvist at "Jul 17, 2003 09:40:16 am" To: Kurt Erik Lindqvist Date: Thu, 24 Jul 2003 17:54:04 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk In the last meeting, it was discussed that: > > at their motivations, timeframes and timeframe. Then look at shorter > > measures that may be applicable. The classification is 'minimal, > > 'small', 'large' and 'international and the slides / draft has the > > details of the classification > > > > Matasaka Ohta: Do you mean that a site may be geographically separated? > > Pekka Savola: yes > > Matsakata Ohta: So full internal connectivity is a requirement for a > > 'site'? > > Pekka Savola: yes > > Erik Nordmark: Its been very fuzzy as to what is a site and its in the > > charter. Its ranged from campus to organization with internal > > connectivity, and we don't need to decide what it is here again. > > > > The motivations listed include ISP independence, redundancy, load > > sharing, and the various aspects of these three areas. Looking at the > > solutions and how they map to this classification it appears that > > multi- > > connecting (same ISP) has some relevance to some shorter timeframes > > in > > some instances. The presentation listed some mechanisms against > > timeframes (see presentation). It should be pointed out that it is not so useful to call an international entity with internal connectivity a site. Such a entity may have a single locator for internal use. Each region may have additional locators supplied from ISPs local to the region. However, it is not necessary that a region share locators of other regions. That is, hosts in such a entity does not have to have so much locators. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jul 24 05:22:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00153 for ; Thu, 24 Jul 2003 05:22:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fcI4-000Bjw-Kz for multi6-data@psg.com; Thu, 24 Jul 2003 09:21:36 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19fcI1-000Biw-Dt for multi6@ops.ietf.org; Thu, 24 Jul 2003 09:21:33 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id A28504312F; Thu, 24 Jul 2003 11:21:02 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.224]) by smtp02.uc3m.es (Postfix) with SMTP id 908A599FAC; Thu, 24 Jul 2003 11:21:02 +0200 (CEST) From: "marcelo bagnulo" To: "Masataka Ohta" Cc: Subject: RE: Fwd: Minutes / Notes Date: Thu, 24 Jul 2003 11:19:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200307240437.NAA04361@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Spam-Status: No, hits=-18.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi Masataka, What about time shifting attacks? I mean you can solve it with RR, but this implies periodical exchanges such as MIPv6. I do agree that DNS packet excahnge are susceptible to this kind of attacks, but currently you have the option of using directly the IP address preventing such attacks. However, if you build an insecure id/locator binding, you cannot prevent them, so i guess we do not want to do this Besides there are flooding attacks, as mentioned in Pekka´s draft. IMHO we should really consider this draft as a valuable input to the design of the solution, since it describes many issues that have to be considered. Underestimating these issues will only delay the solution. Regards, marcelo > -----Mensaje original----- > De: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Enviado el: jueves, 24 de julio de 2003 6:38 > Para: Pekka Nikander > CC: marcelo bagnulo; J. Noel Chiappa; multi6@ops.ietf.org > Asunto: Re: Fwd: Minutes / Notes > > > Pekka; > > > > Binding between locators and identifiers in single packets have > > > just enough security. > > It should also be noted that binding between locators and identifiers > in single DNS reply packets have just enough security. > > > Strongly disagree. See the flooding attacks in > > > http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro- sec-01.txt > > They do not, as such, directly apply to multi-homing, Notification of locator changes, of course, needs its own security, which does not apply to multi-homing issue here, not even indirectly. > but you can fairly easily find out variants that do. Wrong. The variant (or a simple case) is an issue to be addressed by return routability and/or DNS reverse/forward mapping just as current IPv4 or 6. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jul 24 05:32:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00331 for ; Thu, 24 Jul 2003 05:32:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fcRl-000CKc-Aa for multi6-data@psg.com; Thu, 24 Jul 2003 09:31:37 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19fcRh-000CIa-Sv for multi6@ops.ietf.org; Thu, 24 Jul 2003 09:31:34 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 22C2F4312F; Thu, 24 Jul 2003 11:31:03 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.224]) by smtp02.uc3m.es (Postfix) with SMTP id 0CE8C99F8F; Thu, 24 Jul 2003 11:31:03 +0200 (CEST) From: "marcelo bagnulo" To: "Masataka Ohta" , "Pekka Nikander" Cc: Subject: RE: Fwd: Minutes / Notes Date: Thu, 24 Jul 2003 11:29:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200307240320.MAA03808@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Spam-Status: No, hits=-18.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Masataka, Pekka, > -----Mensaje original----- > De: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Enviado el: jueves, 24 de julio de 2003 5:21 > Para: Pekka Nikander > CC: marcelo bagnulo; multi6@ops.ietf.org > Asunto: Re: Fwd: Minutes / Notes > > > Pekka; > > > > For the source endpoint information, i am not sure > > > I think that carrying the source identifier would make more > sense, since it > > > identifies the other endd of the communication. > > > > Carrying a source identifier is harmful. For our argument, see > > > > Catharina Candolin and Pekka Nikander, "IPv6 Source Addresses > Considered > > Harmful," in Hanne Riis Nielson (ed.), Proceedings of NordSec 2001, > > Sixth Nordoc Workshop on Secure IT Systems, November 1-2, Lyngby, > > Denmark, Technical Report IMM-TR-2001-14, pp. 54-68, Technical > > University of Denmark, November 2001. > > > > http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf > > You forgot the fact that the Internet is a public network. > So? What do you mean?, could you be a bit more explicit?. Actually, IMHO it is the oposite, this article assumes that packets are not trusted by default. I mean, most of the time, the information carried in packets such as the source address, has not been modified. (this is essentially due to the fact that nobody is interested in spoofing most of web surfing packets or my email exchange with my friends, since there is no point to do so). So i do not think that we need high crypto security by deafault... So i guess that my question would be: is it a reasonable approach to use crypto in all comunications? (such as HIP) Perhaps this is the most simple way to safely decouple loc and ids (so we do it for simplicity and not because it is the only way to achiev the required security level) Regards, marcelo > Masataka Ohta > From owner-multi6@ops.ietf.org Thu Jul 24 06:03:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01051 for ; Thu, 24 Jul 2003 06:03:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fcuN-000E00-T8 for multi6-data@psg.com; Thu, 24 Jul 2003 10:01:11 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19fcuJ-000Dzk-Ng for multi6@ops.ietf.org; Thu, 24 Jul 2003 10:01:07 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id C9CAB4326D; Thu, 24 Jul 2003 12:01:03 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.224]) by smtp02.uc3m.es (Postfix) with SMTP id 3BBFC99FC7; Thu, 24 Jul 2003 12:01:03 +0200 (CEST) From: "marcelo bagnulo" To: "Masataka Ohta" , "Pekka Nikander" Cc: "Tony Li" , "Erik Nordmark" , Subject: RE: Minutes / Notes Date: Thu, 24 Jul 2003 11:59:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200307240407.NAA04148@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Spam-Status: No, hits=-18.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi again Masataka, > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Masataka Ohta > Enviado el: jueves, 24 de julio de 2003 6:08 > Para: Pekka Nikander > CC: Tony Li; Erik Nordmark; multi6@ops.ietf.org > Asunto: Re: Minutes / Notes > > > Pekka; > > > The important point is, however, that if the id/loc separation > > is done, the source address is not needed by the end-hosts any > > more. It is needed in the very first packet flowing in a direction, > > and perhaps in the second one, until the id->loc state is verified > > and established, but not after that. > > The Internet is connectionless. > What about MIP? I mean, there is a state stored in the IP layer about the CN and which addresses (HoA CoA) are being used in the communication. Perhaps we should explore the possibility that the IP provides a connection oriented service. In such way, the connection is open with a given host and then locators can change (just as MIP does) Regards, marcelo > TCP is not IP, the Internet Protocol. > > Masataka Ohta > From owner-multi6@ops.ietf.org Thu Jul 24 06:45:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01608 for ; Thu, 24 Jul 2003 06:45:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fdab-000GGx-RI for multi6-data@psg.com; Thu, 24 Jul 2003 10:44:49 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19fdaY-000GFE-CG for multi6@ops.ietf.org; Thu, 24 Jul 2003 10:44:46 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 997264327A; Thu, 24 Jul 2003 12:44:15 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.224]) by smtp02.uc3m.es (Postfix) with SMTP id 70CB099FC7; Thu, 24 Jul 2003 12:44:11 +0200 (CEST) From: "marcelo bagnulo" To: "Masataka Ohta" , "Iljitsch van Beijnum" Cc: Subject: RE: Minutes / Notes Date: Thu, 24 Jul 2003 12:42:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200307240844.RAA05300@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Spam-Status: No, hits=-19.3 required=5.0 tests=BAYES_01,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Masataka Ohta > Enviado el: jueves, 24 de julio de 2003 10:45 > Para: Iljitsch van Beijnum > CC: multi6@ops.ietf.org > Asunto: Re: Minutes / Notes > > > Iljitsch; > > > >> I have a few technical (not editorial) comments on some > points in the > > >> minutes, > > >> which are therefore of general interest... > > > > > A problem is that the minutes lacks discussioin on so many errors of > > > Iljitsch's proposal that yo are repeating my points at the meeting > > > > Well, let's hear it then. What are those errors? > > 1) On slide of "loc/id separation", the mapping from FQDN should not be > > FQDN -> ID -> Locators > > but should be > > FQDN -> (ID, Locators) Are you claiming that an ID to locator mapping is not needed? > > to avoid extra mapping and possible security problem. > > 2) On slide of pros and cons of "small", all the "cons" are wrong > as follows. > > 2.1) Work with unaggregatable MAC namespace > or break autoconfiguration > > Structured ID can be autoconfigured by DHCP. > I guess Iljitsch was talking about stateless autoconfig RFC 2462 > > 2.2) Can't trust incoming id-loc association > > Association between an ID and locators is secure if they > are contained in a single packet. No. It is less secure than today usage of IP addresses (not talking about DNS) (see previous mail) Regards, marcelo > > 2.3) If not break, certainly bend transports > > With LIN6 trick, API for TCP stays same. > > 2.4) Changes to both hosts and routers > > There is no changes to routers > > There are other errors I didn't bothered to correct. > > Masataka Ohta > From owner-multi6@ops.ietf.org Thu Jul 24 07:50:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02825 for ; Thu, 24 Jul 2003 07:50:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19feaS-000JPn-PR for multi6-data@psg.com; Thu, 24 Jul 2003 11:48:44 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19feaP-000JPU-SG for multi6@ops.ietf.org; Thu, 24 Jul 2003 11:48:42 +0000 From: Masataka Ohta Message-Id: <200307241137.UAA06377@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA06377; Thu, 24 Jul 2003 20:36:55 +0859 Subject: Re: Fwd: Minutes / Notes In-Reply-To: from marcelo bagnulo at "Jul 24, 2003 11:19:30 am" To: marcelo bagnulo Date: Thu, 24 Jul 2003 20:36:53 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-8.9 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Marcelo; > Hi Masataka, > > What about time shifting attacks? > I mean you can solve it with RR, but this implies periodical exchanges such > as MIPv6. Huh? > I do agree that DNS packet excahnge are susceptible to this kind of attacks, Huh? I'm afraid you don't correctly understand the requirement for weak and strong securities. > IMHO we should really consider this draft as a valuable input to the design > of the solution, since it describes many issues that have to be considered. Your problem is that our design team has already completed the design with all the issues resolved. > Underestimating these issues will only delay the solution. No. We did not underestimate anything and the solution is already available that there is no delay. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jul 24 07:59:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03111 for ; Thu, 24 Jul 2003 07:59:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fekN-000K00-TV for multi6-data@psg.com; Thu, 24 Jul 2003 11:58:59 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fekH-000JzQ-5b for multi6@ops.ietf.org; Thu, 24 Jul 2003 11:58:53 +0000 From: Masataka Ohta Message-Id: <200307241144.UAA06414@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA06414; Thu, 24 Jul 2003 20:44:15 +0900 Subject: Re: Fwd: Minutes / Notes In-Reply-To: from marcelo bagnulo at "Jul 24, 2003 11:29:31 am" To: marcelo bagnulo Date: Thu, 24 Jul 2003 20:44:14 +0859 () CC: Pekka Nikander , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Marcelo; > > You forgot the fact that the Internet is a public network. > So? What do you mean?, could you be a bit more explicit?. On what? Could you be a bit more explicit?. > So i guess that my question would be: is it a reasonable approach to use > crypto in all comunications? (such as HIP) Are you saying autoconfiguration of shared secret for the crypto? I am aware that some people are stupid enough to believe it possible. HIP is a lot less stupid merely assuming that an initial identity is kept cryptographically securely preserved, even though the initial identity is not cryptographycally secured. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jul 24 08:00:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03148 for ; Thu, 24 Jul 2003 08:00:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19felU-000K7J-Do for multi6-data@psg.com; Thu, 24 Jul 2003 12:00:08 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19felR-000K6D-G7 for multi6@ops.ietf.org; Thu, 24 Jul 2003 12:00:05 +0000 From: Masataka Ohta Message-Id: <200307241148.UAA06430@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA06430; Thu, 24 Jul 2003 20:47:45 +0859 Subject: Re: Minutes / Notes In-Reply-To: from marcelo bagnulo at "Jul 24, 2003 11:59:31 am" To: marcelo bagnulo Date: Thu, 24 Jul 2003 20:47:44 +0859 () CC: Pekka Nikander , Tony Li , Erik Nordmark , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Marcelo; > > The Internet is connectionless. > What about MIP? MIP dynamically create a virtual point to point (thus, connection oriented) link layer between end systems. > I mean, there is a state stored in the IP layer about the CN and which > addresses (HoA CoA) are being used in the communication. The state belongs to the virtual link layer below lower IP layer. > Perhaps we should explore the possibility that the IP provides a connection > oriented service. You should better use ATM. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jul 24 08:12:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03456 for ; Thu, 24 Jul 2003 08:12:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fewH-000Krg-2D for multi6-data@psg.com; Thu, 24 Jul 2003 12:11:17 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fewE-000KrH-45 for multi6@ops.ietf.org; Thu, 24 Jul 2003 12:11:14 +0000 From: Masataka Ohta Message-Id: <200307241154.UAA06500@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA06500; Thu, 24 Jul 2003 20:53:51 +0859 Subject: Re: Minutes / Notes In-Reply-To: from marcelo bagnulo at "Jul 24, 2003 12:42:39 pm" To: marcelo bagnulo Date: Thu, 24 Jul 2003 20:53:51 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Marcelo; > > 1) On slide of "loc/id separation", the mapping from FQDN should not be > > > > FQDN -> ID -> Locators > > > > but should be > > > > FQDN -> (ID, Locators) > > Are you claiming that an ID to locator mapping is not needed? No. See (hopefully revised) minutes. > > 2) On slide of pros and cons of "small", all the "cons" are wrong > > as follows. > > > > 2.1) Work with unaggregatable MAC namespace > > or break autoconfiguration > > > > Structured ID can be autoconfigured by DHCP. > > > > I guess Iljitsch was talking about stateless autoconfig RFC 2462 RFC2462 does not give any useful definition of autoconfiguration. For example, in DNSOP WG, people, including those of IPv6 ones, are discussing autoconfiguration with DHCP. > > 2.2) Can't trust incoming id-loc association > > > > Association between an ID and locators is secure if they > > are contained in a single packet. > > No. It is less secure than today usage of IP addresses (not talking about > DNS) > (see previous mail) It is as secure as the Internet today with an address binded both to an ID and an locator. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jul 24 08:47:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04221 for ; Thu, 24 Jul 2003 08:47:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ffUO-000Mtn-C6 for multi6-data@psg.com; Thu, 24 Jul 2003 12:46:32 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19ffUL-000Mt6-UC for multi6@ops.ietf.org; Thu, 24 Jul 2003 12:46:30 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 8E6791C; Thu, 24 Jul 2003 15:55:36 +0300 (EEST) Message-ID: <3F1FD505.2070007@nomadiclab.com> Date: Thu, 24 Jul 2003 15:45:57 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo Cc: Masataka Ohta , multi6@ops.ietf.org Subject: Reasonable to use crypto in all communications? (Re: Fwd: Minutes / Notes) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So i guess that my question would be: is it a reasonable approach to use > crypto in all comunications? (such as HIP) I don't think so. There certainly is some communication that does not need any protection at all in addition to what is provided by the application layer. On the other hand, it has been stated that there certainly is some communication that does not need the added flexibility and robustness provided by the id/loc separation. Now, there is a good question: Do we get four distinct subsets, each of a reasonably big size, or is any of the four subsets so small that we can almost ignore it: - non-robust, non-flexible, non-protected traffic (current IP) - non-robust, non-flexible, protected traffic (current IPsec?) - maybe-multihomed, maybe-mobile, non-protected traffic - maybe-multihomed, maybe-mobile, protected traffic The id/loc mapping itself needs some kind of protection, or otherwise we get new nasty DDoS attacks using all hosts, even uncompromized ones, as zombies. The actual traffic may or may not need protection. It is a know deficiency in the current HIP spec that it does not directly support non-protected traffic. However, if unencrypted, non-integrity protected ESP was allowed, one could use the SPI in the ESP header as a kind of condensed identifier, without any cryptographic protection. --Pekka Nikander From owner-multi6@ops.ietf.org Thu Jul 24 09:01:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04643 for ; Thu, 24 Jul 2003 09:01:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ffgP-000Nkw-I0 for multi6-data@psg.com; Thu, 24 Jul 2003 12:58:57 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19ffgN-000Nj8-0Y for multi6@ops.ietf.org; Thu, 24 Jul 2003 12:58:55 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id E0E051C; Thu, 24 Jul 2003 16:08:01 +0300 (EEST) Message-ID: <3F1FD7EE.2070005@nomadiclab.com> Date: Thu, 24 Jul 2003 15:58:22 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masataka Ohta Cc: multi6@ops.ietf.org Subject: Re: Fwd: Minutes / Notes References: <200307240437.NAA04361@necom830.hpcl.titech.ac.jp> In-Reply-To: <200307240437.NAA04361@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka, > It should also be noted that binding between locators and identifiers > in single DNS reply packets have just enough security. No, it doesn't, see below. >>Strongly disagree. See the flooding attacks in ... >>but you can fairly easily find out variants that do. > > Wrong. > > The variant (or a simple case) is an issue to be addressed by > return routability and/or DNS reverse/forward mapping just as > current IPv4 or 6. Please get your facts right. 1. I create the following DNS records for myself (using A here for AAAA just to make the point...) pnr.iki.fi. IN IDENTITY XXX pnr.iki.fi. IN A 131.112.32.132 pnr.iki.fi. IN A 81.17.193.194 [For those who don't want to check, 81.17.193.194 is pnr.iki.fi, 131.112.32.132 is necom830.hpcl.titech.ac.jp] 2. I order a large number of streams, all associated with XXX, directed to 81.17.193.194 These can be TCP or UDP streams... 3. I start sending acknowledgements with source address spoofed to 131.112.32.132 4. The hosts shipping the streams think that my link to 81.17.193.194 has just crashed, and start shipping the packets to 131.112.32.132 The rest should be clear. Yes, you can defeat this particular scenario by saying that in IPv6 ingress filtering will be universally deployed, but there are other, more complex ones where ingress filtering does not necessarily help. --Pekka Nikander From owner-multi6@ops.ietf.org Thu Jul 24 11:24:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10914 for ; Thu, 24 Jul 2003 11:24:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fhuc-0006LA-EP for multi6-data@psg.com; Thu, 24 Jul 2003 15:21:46 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19fhuV-0006KL-A7 for multi6@ops.ietf.org; Thu, 24 Jul 2003 15:21:39 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 87A4543150; Thu, 24 Jul 2003 17:21:08 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.224]) by smtp02.uc3m.es (Postfix) with SMTP id 78D9A99FBC; Thu, 24 Jul 2003 17:21:08 +0200 (CEST) From: "marcelo bagnulo" To: "Pekka Nikander" Cc: Subject: RE: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/ Notes) Date: Thu, 24 Jul 2003 17:19:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3F1FD505.2070007@nomadiclab.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Spam-Status: No, hits=-19.3 required=5.0 tests=BAYES_01,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Pekka Nikander > Enviado el: jueves, 24 de julio de 2003 14:46 > Para: marcelo bagnulo > CC: Masataka Ohta; multi6@ops.ietf.org > Asunto: Reasonable to use crypto in all communications? (Re: Fwd: > Minutes/ Notes) > > > > So i guess that my question would be: is it a reasonable approach to use > > crypto in all comunications? (such as HIP) > > I don't think so. There certainly is some communication that > does not need any protection at all in addition to what is > provided by the application layer. > > On the other hand, it has been stated that there certainly is > some communication that does not need the added flexibility and > robustness provided by the id/loc separation. > > Now, there is a good question: Do we get four distinct subsets, > each of a reasonably big size, or is any of the four subsets > so small that we can almost ignore it: > > - non-robust, non-flexible, non-protected traffic (current IP) > - non-robust, non-flexible, protected traffic (current IPsec?) > - maybe-multihomed, maybe-mobile, non-protected traffic > - maybe-multihomed, maybe-mobile, protected traffic I would say that none of those 4 types can be negliged. > > The id/loc mapping itself needs some kind of protection, or otherwise > we get new nasty DDoS attacks using all hosts, even uncompromized > ones, as zombies. The actual traffic may or may not need protection. > It is a know deficiency in the current HIP spec that it does not > directly support non-protected traffic. However, if unencrypted, > non-integrity protected ESP was allowed, one could use the SPI > in the ESP header as a kind of condensed identifier, without > any cryptographic protection. > I am not so sure. I would say that inlcuding unprotected identifiers instead of unprotected locators is weaker, since locators are somehow verified by the routing system and ingress filtering and identifiers (as currenlty proposed) are not verified. I mean, it would be trivial to impersonate an identifier, since the packet would be routed using the locator (this is not the case if locator and identifier are the same). Am i missing something? marcelo > --Pekka Nikander > > > From owner-multi6@ops.ietf.org Thu Jul 24 11:32:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11094 for ; Thu, 24 Jul 2003 11:32:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fi4H-0006zW-1b for multi6-data@psg.com; Thu, 24 Jul 2003 15:31:45 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19fi4B-0006wz-Pc for multi6@ops.ietf.org; Thu, 24 Jul 2003 15:31:39 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 0D9E543272; Thu, 24 Jul 2003 17:31:09 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.224]) by smtp02.uc3m.es (Postfix) with SMTP id EFD4C99FB6; Thu, 24 Jul 2003 17:31:08 +0200 (CEST) From: "marcelo bagnulo" To: "Masataka Ohta" Cc: Subject: RE: Fwd: Minutes / Notes Date: Thu, 24 Jul 2003 17:29:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200307241137.UAA06377@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Spam-Status: No, hits=-19.3 required=5.0 tests=BAYES_01,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Masataka Ohta > Enviado el: jueves, 24 de julio de 2003 13:38 > Para: marcelo bagnulo > CC: multi6@ops.ietf.org > Asunto: Re: Fwd: Minutes / Notes > > > Marcelo; > > > Hi Masataka, > > > > What about time shifting attacks? > > I mean you can solve it with RR, but this implies periodical > exchanges such > > as MIPv6. > > Huh? Please read MIPv6 spec and Pekka´s draft about ro security design > > > I do agree that DNS packet excahnge are susceptible to this > kind of attacks, > > Huh? > > I'm afraid you don't correctly understand the requirement for weak and > strong securities. > I was agreeing with you, so i am not sure what we are discussing now :-) > > IMHO we should really consider this draft as a valuable input > to the design > > of the solution, since it describes many issues that have to be > considered. > > Your problem is that our design team has already completed the design > with all the issues resolved. > This is not a problem, it is great! Could you please give us a pointer to the documents that explain the security issues? Regards, marcelo > > Underestimating these issues will only delay the solution. > > No. We did not underestimate anything and the solution is already > available that there is no delay. > > Masataka Ohta > From owner-multi6@ops.ietf.org Thu Jul 24 11:40:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11297 for ; Thu, 24 Jul 2003 11:40:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fiBK-0007U7-LC for multi6-data@psg.com; Thu, 24 Jul 2003 15:39:02 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19fiB9-0007Rc-Vq for multi6@ops.ietf.org; Thu, 24 Jul 2003 15:38:52 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 83DDF1C; Thu, 24 Jul 2003 18:47:58 +0300 (EEST) Message-ID: <3F1FFD6C.6090607@nomadiclab.com> Date: Thu, 24 Jul 2003 18:38:20 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo Cc: multi6@ops.ietf.org Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/ Notes) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: >>It is a know deficiency in the current HIP spec that it does not >>directly support non-protected traffic. However, if unencrypted, >>non-integrity protected ESP was allowed, one could use the SPI >>in the ESP header as a kind of condensed identifier, without >>any cryptographic protection. > > I am not so sure. > I would say that inlcuding unprotected identifiers instead of unprotected > locators is weaker, since locators are somehow verified by the routing > system and ingress filtering and identifiers (as currenlty proposed) are not > verified. I mean, it would be trivial to impersonate an identifier, since > the packet would be routed using the locator (this is not the case if > locator and identifier are the same). Am i missing something? Using an unprotected identifier (or a pointer to a cached identifier) allows an attacker to send packets that may be delivered to a wrong socket. I don't see anything new there. Allowing an unprotected packet to set up or change identifier -> locator mapping seems to be dangerous. Return routability based on a cryptographic challenge-response that binds the different addresses genuinely together looks like a secure enough solution. However, it is hard to implement in fewer than 3-4 messages (1.5 to two round trips) without opening a resource exhaustion danger at the passive end. An IP layer resource exhaustion attack would be more severe than a TCP layer one, IMHO. --Pekka Nikander From owner-multi6@ops.ietf.org Thu Jul 24 12:18:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12342 for ; Thu, 24 Jul 2003 12:18:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fimH-000ABY-1D for multi6-data@psg.com; Thu, 24 Jul 2003 16:17:13 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19fimD-000A8Z-Sv for multi6@ops.ietf.org; Thu, 24 Jul 2003 16:17:10 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 37F6B432F3; Thu, 24 Jul 2003 18:07:03 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.224]) by smtp02.uc3m.es (Postfix) with SMTP id 236CD99F8D; Thu, 24 Jul 2003 18:07:03 +0200 (CEST) From: "marcelo bagnulo" To: "Pekka Nikander" Cc: Subject: RE: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) Date: Thu, 24 Jul 2003 18:05:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3F1FFD6C.6090607@nomadiclab.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Spam-Status: No, hits=-19.3 required=5.0 tests=BAYES_01,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Using an unprotected identifier (or a pointer to a cached > identifier) allows an attacker to send packets that may > be delivered to a wrong socket. I don't see anything new there. > > Allowing an unprotected packet to set up or change > identifier -> locator mapping seems to be dangerous. This is the case i was thinking about, i.e. packets carrying both id and locator unprotected (and that haven?t been previously bound in a secure way) If this is dangerous, a possibility is to use some sort of crypto for each node that you are communicating with in order to perform the binding. the other possibility is some sort of RR check, as you mention below. Other choices? My original question was if a solution that rerquires crypto for each communication (not for every packet) is acceptable. The problem with RR check is that it has to be done periodically in order to prevent time shifting attacks. However, in the multi-homed case, perhaps this could be avoided. I mean, an important difference between mobility and multi-homing is that in multi-homing all the possible addresses are known in advance. this means that they can be exchanged when the communication with the other end is initiated. This reduces the critical packets to the initial ones. So perhaps a solution that performs a RR check to all possible addresses of a communication when the communication is initiated would be acceptable. There are still some time shifting attacks that have to be considered though. Perhaps crypto would provide a simpler solution anyway Regards, marcelo > > Return routability based on a cryptographic challenge-response > that binds the different addresses genuinely together looks > like a secure enough solution. However, it is hard to > implement in fewer than 3-4 messages (1.5 to two round trips) > without opening a resource exhaustion danger at the passive end. > An IP layer resource exhaustion attack would be more severe > than a TCP layer one, IMHO. > > --Pekka Nikander > > From owner-multi6@ops.ietf.org Thu Jul 24 12:19:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12382 for ; Thu, 24 Jul 2003 12:19:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19finy-000AK8-CB for multi6-data@psg.com; Thu, 24 Jul 2003 16:18:58 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19finr-000AHz-HZ for multi6@ops.ietf.org; Thu, 24 Jul 2003 16:18:51 +0000 From: Masataka Ohta Message-Id: <200307241610.BAA07075@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA07075; Fri, 25 Jul 2003 01:10:08 +0900 Subject: Re: Fwd: Minutes / Notes In-Reply-To: <3F1FD7EE.2070005@nomadiclab.com> from Pekka Nikander at "Jul 24, 2003 03:58:22 pm" To: Pekka Nikander Date: Fri, 25 Jul 2003 01:10:07 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka Nikander; > > It should also be noted that binding between locators and identifiers > > in single DNS reply packets have just enough security. > > No, it doesn't, see below. Yes, it does. > > The variant (or a simple case) is an issue to be addressed by > > return routability and/or DNS reverse/forward mapping just as > > current IPv4 or 6. > > Please get your facts right. > > 1. I create the following DNS records for myself > (using A here for AAAA just to make the point...) > > pnr.iki.fi. IN IDENTITY XXX > pnr.iki.fi. IN A 131.112.32.132 > pnr.iki.fi. IN A 81.17.193.194 > > [For those who don't want to check, > 81.17.193.194 is pnr.iki.fi, > 131.112.32.132 is necom830.hpcl.titech.ac.jp] > > 2. I order a large number of streams, all > associated with XXX, directed to 81.17.193.194 > These can be TCP or UDP streams... > > 3. I start sending acknowledgements with source > address spoofed to 131.112.32.132 > > 4. The hosts shipping the streams think that my > link to 81.17.193.194 has just crashed, and > start shipping the packets to 131.112.32.132 > > The rest should be clear. Ignoring the mistake that using source address of 131.112.32.132 does not make its peer that 81.17.193.194 has crashed... Yes, lacking proper acknowledgements from 131.112.32.132, the peer will terminate the stream. That is, you can't send proper acknowledgements, unless you can receive packets to 131.112.32.132, which is the return routability. It should also be noted that there is no amplificaiton here that it is no worse than ICMP echo requests with spoofed source addresses. > Yes, you can defeat > this particular scenario by saying that in IPv6 > ingress filtering will be universally deployed, > but there are other, more complex ones where > ingress filtering does not necessarily help. Yes, similar attack is, for example, possible with pnr.iki.fi. IN MX 10 pnr.iki.fi, pnr.iki.fi. IN MX 20 necom830.hpcl.titech.ac.jp pnr.iki.fi. IN A 81.17.193.194 necom830.hpcl.titech.ac.jp IN A 131.112.32.132 and sending a lot of erroneous mails from pnr.iki.fi to random recipients. So? Masataka Ohta From owner-multi6@ops.ietf.org Thu Jul 24 12:30:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12994 for ; Thu, 24 Jul 2003 12:30:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fixb-000B4i-T5 for multi6-data@psg.com; Thu, 24 Jul 2003 16:28:55 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fixX-000B2B-30 for multi6@ops.ietf.org; Thu, 24 Jul 2003 16:28:51 +0000 From: Masataka Ohta Message-Id: <200307241615.BAA07128@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA07128; Fri, 25 Jul 2003 01:14:59 +0859 Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes / Notes) In-Reply-To: <3F1FD505.2070007@nomadiclab.com> from Pekka Nikander at "Jul 24, 2003 03:45:57 pm" To: Pekka Nikander Date: Fri, 25 Jul 2003 01:14:58 +0859 () CC: marcelo bagnulo , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka Nikander; > The id/loc mapping itself needs some kind of protection, For most mapping, cookie is the protection. For mobility mapping, the protection should use shared secret. > However, if unencrypted, > non-integrity protected ESP was allowed, one could use the SPI > in the ESP header as a kind of condensed identifier, without > any cryptographic protection. It is a poor form of cookie with so much extra overhead. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jul 24 12:41:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13655 for ; Thu, 24 Jul 2003 12:41:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fj94-000Bxx-27 for multi6-data@psg.com; Thu, 24 Jul 2003 16:40:46 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19fj90-000BwC-6O for multi6@ops.ietf.org; Thu, 24 Jul 2003 16:40:42 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 968A21C; Thu, 24 Jul 2003 19:49:48 +0300 (EEST) Message-ID: <3F200BEA.8070801@nomadiclab.com> Date: Thu, 24 Jul 2003 19:40:10 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masataka Ohta Cc: multi6@ops.ietf.org Subject: Re: Fwd: Minutes / Notes References: <200307241610.BAA07075@necom830.hpcl.titech.ac.jp> In-Reply-To: <200307241610.BAA07075@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka Ohta wrote: > Yes, lacking proper acknowledgements from 131.112.32.132, the > peer will terminate the stream. Exactly. > That is, you can't send proper acknowledgements, unless you can > receive packets to 131.112.32.132, which is the return routability. Not true. If you open a TCP session and receive the first few packets, it is easy enough to generate fake ACKs. I can dig up a reference if needed. You can even make it look like the bandwidth is much higher than it is, thereby clogging a pipe even with just one or few streams. All you need to do is to get a stream that is originally directed to yourself to be now directed to the victim, with the possibility of generating faked ACKs. Some people claim that it is even easier to fake ACKs for some UDP based protocols, but I don't know the details. > It should also be noted that there is no amplificaiton here that > it is no worse than ICMP echo requests with spoofed source addresses. Not true, see above. > Yes, similar attack is, for example, possible with > > pnr.iki.fi. IN MX 10 pnr.iki.fi, > pnr.iki.fi. IN MX 20 necom830.hpcl.titech.ac.jp > pnr.iki.fi. IN A 81.17.193.194 > necom830.hpcl.titech.ac.jp IN A 131.112.32.132 > > and sending a lot of erroneous mails from pnr.iki.fi to > random recipients. > > So? The problem is that the attacker is able to make the stream to continue uninterrupted, since it can fake the acks very easily. If you make a false MX, the MXed host will not accept the mail. Hence, in that case application level stops the attack. --Pekka Nikander From owner-multi6@ops.ietf.org Thu Jul 24 12:43:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13691 for ; Thu, 24 Jul 2003 12:43:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fjAu-000C4r-Ip for multi6-data@psg.com; Thu, 24 Jul 2003 16:42:40 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19fjAs-000C3R-0u for multi6@ops.ietf.org; Thu, 24 Jul 2003 16:42:38 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 7F69E1C; Thu, 24 Jul 2003 19:51:44 +0300 (EEST) Message-ID: <3F200C5E.10807@nomadiclab.com> Date: Thu, 24 Jul 2003 19:42:06 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masataka Ohta Cc: marcelo bagnulo , multi6@ops.ietf.org Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes / Notes) References: <200307241615.BAA07128@necom830.hpcl.titech.ac.jp> In-Reply-To: <200307241615.BAA07128@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka Ohta wrote: >>The id/loc mapping itself needs some kind of protection, > > For most mapping, cookie is the protection. > For mobility mapping, the protection should use shared secret. Depending on the definition of cookie, I may agree. Depending on how you get the shared secret, I may agree. Hence, please be more specific. And please explain in detail how you *bootstrap* the system. Assuming a global PKI is not a solution. --Pekka Nikander From owner-multi6@ops.ietf.org Thu Jul 24 13:20:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16633 for ; Thu, 24 Jul 2003 13:20:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fjjw-000F80-3w for multi6-data@psg.com; Thu, 24 Jul 2003 17:18:52 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fjjs-000F7g-J3 for multi6@ops.ietf.org; Thu, 24 Jul 2003 17:18:48 +0000 From: Masataka Ohta Message-Id: <200307241711.CAA07345@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA07345; Fri, 25 Jul 2003 02:11:29 +0900 Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes / Notes) In-Reply-To: <3F200C5E.10807@nomadiclab.com> from Pekka Nikander at "Jul 24, 2003 07:42:06 pm" To: Pekka Nikander Date: Fri, 25 Jul 2003 02:11:29 +0859 () CC: marcelo bagnulo , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka Nikander; > >>The id/loc mapping itself needs some kind of protection, > > > > For most mapping, cookie is the protection. > > For mobility mapping, the protection should use shared secret. > > Depending on the definition of cookie, I may agree. > Depending on how you get the shared secret, I may agree. > > Hence, please be more specific. And please explain in > detail how you *bootstrap* the system. It is of course that cookie is exchanged with three way handshake and the shared secret is shared OOB. Note that the shared secret is necessary only between HA and MH (rest is done by cookie) that the secret is shared when MH owner asks HA service to the administrator of the HA and configured to MH when a HA address is configured. > Assuming a global PKI is not a solution. I know very well why PKI is not useful. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jul 24 13:41:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17405 for ; Thu, 24 Jul 2003 13:41:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fk3A-000Gdk-Si for multi6-data@psg.com; Thu, 24 Jul 2003 17:38:44 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fk37-000GdX-RT for multi6@ops.ietf.org; Thu, 24 Jul 2003 17:38:42 +0000 From: Masataka Ohta Message-Id: <200307241728.CAA07568@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA07568; Fri, 25 Jul 2003 02:27:51 +0859 Subject: Re: Fwd: Minutes / Notes In-Reply-To: <3F200BEA.8070801@nomadiclab.com> from Pekka Nikander at "Jul 24, 2003 07:40:10 pm" To: Pekka Nikander Date: Fri, 25 Jul 2003 02:27:50 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka; > > Yes, lacking proper acknowledgements from 131.112.32.132, the > > peer will terminate the stream. > > Exactly. > > > That is, you can't send proper acknowledgements, unless you can > > receive packets to 131.112.32.132, which is the return routability. > > Not true. If you open a TCP session and receive the first > few packets, it is easy enough to generate fake ACKs. Assuming that there is no packet losses and that the attacker send acks slowly enough, maybe. > I can dig up a reference if needed. You can even make > it look like the bandwidth is much higher than it is, > thereby clogging a pipe even with just one or few > streams. See above. > All you need to do is to get a stream that > is originally directed to yourself to be now directed > to the victim, with the possibility of generating faked > ACKs. Note also that there is no victim host. See below. > Some people claim that it is even easier to fake ACKs > for some UDP based protocols, but I don't know the details. You can, of course, design such protocols by yourself. However, hosts supporting such protocols are compromised from the beginning. > > It should also be noted that there is no amplificaiton here that > > it is no worse than ICMP echo requests with spoofed source addresses. > > Not true, see above. Actually, it is weaker than echo attack, because packets to XXX is never received by any IP layer and ICMP host unreachable will be returned. > > Yes, similar attack is, for example, possible with > > > > pnr.iki.fi. IN MX 10 pnr.iki.fi, > > pnr.iki.fi. IN MX 20 necom830.hpcl.titech.ac.jp > > pnr.iki.fi. IN A 81.17.193.194 > > necom830.hpcl.titech.ac.jp IN A 131.112.32.132 > > > > and sending a lot of erroneous mails from pnr.iki.fi to > > random recipients. > > > > So? > > The problem is that the attacker is able to make the > stream to continue uninterrupted, since it can fake > the acks very easily. See above. > If you make a false MX, the MXed host will not > accept the mail. Hence, in that case application > level stops the attack. Only after the resource of transport and application layers is wasted, which means a successful DoS attack. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jul 24 14:54:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21459 for ; Thu, 24 Jul 2003 14:54:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19flC3-000Lwr-3E for multi6-data@psg.com; Thu, 24 Jul 2003 18:51:59 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19flB4-000Lt1-FD for multi6@ops.ietf.org; Thu, 24 Jul 2003 18:50:58 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6OIpVxS075835; Thu, 24 Jul 2003 20:51:31 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 24 Jul 2003 20:50:52 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Iljitsch van Beijnum In-Reply-To: <200307240844.RAA05300@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, jul 24, 2003, at 10:44 Europe/Amsterdam, Masataka Ohta wrote: >> Well, let's hear it then. What are those errors? > 1) On slide of "loc/id separation", the mapping from FQDN should not be > FQDN -> ID -> Locators > but should be > FQDN -> (ID, Locators) > to avoid extra mapping and possible security problem. That's not an error. There is no way to pass all locators to the socket API. > 2) On slide of pros and cons of "small", all the "cons" are wrong as > follows. > 2.1) Work with unaggregatable MAC namespace > or break autoconfiguration > Structured ID can be autoconfigured by DHCP. DHCP doesn't exist (yet) in IPv6. And for good reason: it is very hard to operate this in a useful way. > 2.2) Can't trust incoming id-loc association > Association between an ID and locators is secure if they > are contained in a single packet. So if I call you and say my name is George W. Bush and give you my phone number, you believe the mapping between Bush' identity and my phone number is correct because it all happened in one exchange? From owner-multi6@ops.ietf.org Thu Jul 24 15:13:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24422 for ; Thu, 24 Jul 2003 15:13:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19flV7-000NRv-JP for multi6-data@psg.com; Thu, 24 Jul 2003 19:11:41 +0000 Received: from [195.43.225.73] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.14) id 19flV4-000NRa-UU for multi6@ops.ietf.org; Thu, 24 Jul 2003 19:11:39 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6OJBCFJ004518; Thu, 24 Jul 2003 21:11:16 +0200 (CEST) Date: Thu, 24 Jul 2003 17:58:09 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Pekka Nikander , Tony Li , Erik Nordmark , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200307240626.PAA04677@necom830.hpcl.titech.ac.jp> Message-Id: <9F157D7C-BDEF-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-33.7 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06,EMAIL_ATTRIBUTION,IN_REP_TO, PGP_SIGNATURE,QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES, UPPERCASE_25_50,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On torsdag, jul 24, 2003, at 08:27 Europe/Stockholm, Masataka Ohta wrote: >> < Id -> locator > mapping / binding / whatever is state. > > Huh? State? > > IP layer does have certain state such as that for routing table, > which does not make it connection oriented. Mapping would create state. State != connection oriented. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyACHaarNKXTPFCVEQJ4+gCbB67AfS+ddPCP0Y8YDyiZLaMjuUUAoM9x of2CShPdRilvvNvDQykBS9Ol =VQ2a -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Jul 24 18:53:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05115 for ; Thu, 24 Jul 2003 18:53:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fovq-000CWA-9n for multi6-data@psg.com; Thu, 24 Jul 2003 22:51:30 +0000 Received: from [171.68.223.138] (helo=sj-core-4.cisco.com) by psg.com with esmtp (Exim 4.14) id 19fovo-000CUl-78 for multi6@ops.ietf.org; Thu, 24 Jul 2003 22:51:28 +0000 Received: from cisco.com (sjc-vpn1-409.cisco.com [10.21.97.153]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6OMospp015807; Thu, 24 Jul 2003 15:50:54 -0700 (PDT) Message-ID: <3F2062CD.7030306@cisco.com> Date: Thu, 24 Jul 2003 15:50:53 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: "J. Noel Chiappa" , multi6@ops.ietf.org Subject: Re: Fwd: Minutes / Notes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema wrote: > iii) Use multiple addresses, one of which is a "virtual address" that is > guaranteed to be reachable all the time, albeit slowly. Use the virtual > address to start connections. Use MIPv6 mechanisms to divert to an > actual address. What do you do when the network hosting your HA drops dead? Eliot From owner-multi6@ops.ietf.org Thu Jul 24 18:54:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05141 for ; Thu, 24 Jul 2003 18:54:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19foxM-000Cbg-Iu for multi6-data@psg.com; Thu, 24 Jul 2003 22:53:04 +0000 Received: from [171.68.223.138] (helo=sj-core-4.cisco.com) by psg.com with esmtp (Exim 4.14) id 19foxK-000CaO-LC for multi6@ops.ietf.org; Thu, 24 Jul 2003 22:53:02 +0000 Received: from cisco.com (sjc-vpn1-409.cisco.com [10.21.97.153]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6OMqSpp016659; Thu, 24 Jul 2003 15:52:29 -0700 (PDT) Message-ID: <3F20632C.9040507@cisco.com> Date: Thu, 24 Jul 2003 15:52:28 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: Keith Moore , S Woodside , multi6@ops.ietf.org Subject: Re: Minutes / Notes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema wrote: >>many p2p apps do their own routing because they are forced to do so, >>not because this is a desirable or acceptable burden to impose on >>applications. also, what works acceptably well in a system to >>transfer widely-replicated files does not necessarily work well in a >>system where host identity is important. > > > There are pretty few systems were "host identity" is what really > matters; in most cases, you want something like domain or user identity. > For example, "www.google.com" is not exactly 1 single host. Right. See draft-irtf-nsrg-report-09.txt Eliot From owner-multi6@ops.ietf.org Thu Jul 24 18:59:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05283 for ; Thu, 24 Jul 2003 18:59:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fp2T-000D5y-Es for multi6-data@psg.com; Thu, 24 Jul 2003 22:58:21 +0000 Received: from [160.36.58.43] (helo=astro.cs.utk.edu) by psg.com with esmtp (Exim 4.14) id 19fp2Q-000D5C-R5 for multi6@ops.ietf.org; Thu, 24 Jul 2003 22:58:18 +0000 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6OMutJ18265; Thu, 24 Jul 2003 18:56:56 -0400 (EDT) Date: Thu, 24 Jul 2003 18:56:55 -0400 From: Keith Moore To: Eliot Lear Cc: moore@cs.utk.edu, huitema@windows.microsoft.com, sbwoodside@yahoo.com, multi6@ops.ietf.org Subject: Re: Minutes / Notes Message-Id: <20030724185655.687d6468.moore@cs.utk.edu> In-Reply-To: <3F20632C.9040507@cisco.com> References: <3F20632C.9040507@cisco.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-25.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Christian Huitema wrote: > > >>many p2p apps do their own routing because they are forced to do so, > >>not because this is a desirable or acceptable burden to impose on > >>applications. also, what works acceptably well in a system to > >>transfer widely-replicated files does not necessarily work well in a > >>system where host identity is important. > > > > > > There are pretty few systems were "host identity" is what really > > matters; in most cases, you want something like domain or user > > identity. For example, "www.google.com" is not exactly 1 single > > host. > > Right. See draft-irtf-nsrg-report-09.txt no, wrong. and there are lots of other things in that report that are also bogus. From owner-multi6@ops.ietf.org Thu Jul 24 19:35:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05964 for ; Thu, 24 Jul 2003 19:35:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fpat-000FKz-1w for multi6-data@psg.com; Thu, 24 Jul 2003 23:33:55 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19fpao-000FKg-O3 for multi6@ops.ietf.org; Thu, 24 Jul 2003 23:33:50 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jul 2003 16:33:48 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jul 2003 16:33:59 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 24 Jul 2003 16:33:48 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jul 2003 16:33:48 -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); Thu, 24 Jul 2003 16:33:41 -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.0); Thu, 24 Jul 2003 16:33:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: Fwd: Minutes / Notes Date: Thu, 24 Jul 2003 16:31:20 -0700 Message-ID: Thread-Topic: Fwd: Minutes / Notes Thread-Index: AcNSNj/i02JFriO9TXuT4zBJlMyA3gABIcJA From: "Christian Huitema" To: "Eliot Lear" Cc: "J. Noel Chiappa" , X-OriginalArrivalTime: 24 Jul 2003 23:33:47.0238 (UTC) FILETIME=[07699060:01C3523C] X-Spam-Status: No, hits=-9.6 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > iii) Use multiple addresses, one of which is a "virtual address" that is > > guaranteed to be reachable all the time, albeit slowly. Use the virtual > > address to start connections. Use MIPv6 mechanisms to divert to an > > actual address. >=20 > What do you do when the network hosting your HA drops dead? That's why I was mentioning a virtual address rather than an HA. Are you familiar with the distributed hash table algorithms? Basically, a DHT is a reliable overlay on top of an arbitrary network. In a classic DHT design, nodes have identifiers randomly spread in a large number space. They maintain "routing tables" that allow them to forward a request for a given number to the host most likely to know about it, etc. The common trade-off is to have routing tables that scale as the logarithm of the size of the network (O(log N)), while the number of relays required to reach a specific destination also scales as O(log N). The routing table would contain the current addresses/locators associated with the identifier. -- Christian Huitema From owner-multi6@ops.ietf.org Thu Jul 24 19:38:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06026 for ; Thu, 24 Jul 2003 19:38:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fpel-000Fao-Hh for multi6-data@psg.com; Thu, 24 Jul 2003 23:37:55 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.14) id 19fpej-000Fa2-2j for multi6@ops.ietf.org; Thu, 24 Jul 2003 23:37:53 +0000 Received: from cisco.com (sjc-vpn1-409.cisco.com [10.21.97.153]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6ONbJuG012692; Thu, 24 Jul 2003 16:37:19 -0700 (PDT) Message-ID: <3F206DAE.7010801@cisco.com> Date: Thu, 24 Jul 2003 16:37:18 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: "J. Noel Chiappa" , multi6@ops.ietf.org Subject: Re: Fwd: Minutes / Notes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema wrote: >>>iii) Use multiple addresses, one of which is a "virtual address" > > that is > >>>guaranteed to be reachable all the time, albeit slowly. Use the > > virtual > >>>address to start connections. Use MIPv6 mechanisms to divert to an >>>actual address. >> >>What do you do when the network hosting your HA drops dead? > > > That's why I was mentioning a virtual address rather than an HA. Are you > familiar with the distributed hash table algorithms? Basically, a DHT is > a reliable overlay on top of an arbitrary network. In a classic DHT > design, nodes have identifiers randomly spread in a large number space. > They maintain "routing tables" that allow them to forward a request for > a given number to the host most likely to know about it, etc. The common > trade-off is to have routing tables that scale as the logarithm of the > size of the network (O(log N)), while the number of relays required to > reach a specific destination also scales as O(log N). The routing table > would contain the current addresses/locators associated with the > identifier. Sounds cool. Got draft? Eliot From owner-multi6@ops.ietf.org Thu Jul 24 19:47:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06206 for ; Thu, 24 Jul 2003 19:47:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fpme-000GAZ-Lf for multi6-data@psg.com; Thu, 24 Jul 2003 23:46:04 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.14) id 19fpmZ-000G6J-Sm for multi6@ops.ietf.org; Thu, 24 Jul 2003 23:45:59 +0000 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 24 Jul 2003 16:45:30 -0700 Received: from cisco.com (sjc-vpn4-540.cisco.com [10.21.82.28]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6ONjRuG017247; Thu, 24 Jul 2003 16:45:27 -0700 (PDT) Message-ID: <3F206F97.4030704@cisco.com> Date: Thu, 24 Jul 2003 16:45:27 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore CC: huitema@windows.microsoft.com, sbwoodside@yahoo.com, multi6@ops.ietf.org Subject: Re: Minutes / Notes References: <3F20632C.9040507@cisco.com> <20030724185655.687d6468.moore@cs.utk.edu> In-Reply-To: <20030724185655.687d6468.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Keith, The example Christian sited is precisely what is addressed in that draft at one point. Perhaps what is bogus is your view of the draft. Eliot Keith Moore wrote: >>>There are pretty few systems were "host identity" is what really >>>matters; in most cases, you want something like domain or user >>>identity. For example, "www.google.com" is not exactly 1 single >>>host. >> >>Right. See draft-irtf-nsrg-report-09.txt > > > no, wrong. and there are lots of other things in that report that are > also bogus. > > > From owner-multi6@ops.ietf.org Thu Jul 24 19:49:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06253 for ; Thu, 24 Jul 2003 19:49:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fppJ-000GL0-8J for multi6-data@psg.com; Thu, 24 Jul 2003 23:48:49 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fppG-000GKf-E3 for multi6@ops.ietf.org; Thu, 24 Jul 2003 23:48:46 +0000 From: Masataka Ohta Message-Id: <200307242335.IAA08506@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA08506; Fri, 25 Jul 2003 08:35:43 +0900 Subject: Re: Minutes / Notes In-Reply-To: from Iljitsch van Beijnum at "Jul 24, 2003 08:50:52 pm" To: Iljitsch van Beijnum Date: Fri, 25 Jul 2003 08:35:43 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > >> Well, let's hear it then. What are those errors? > > > 1) On slide of "loc/id separation", the mapping from FQDN should not be > > > FQDN -> ID -> Locators > > > but should be > > > FQDN -> (ID, Locators) > > > to avoid extra mapping and possible security problem. > > That's not an error. There is no way to pass all locators to the socket > API. It means that there are additional errors. First, it is not an API issue that, if multihoming can be handled by the transport layer like TCP case, you can keep the current API. Second, it is trivially easy to add a new address family to the socket API to pass multiple addresses to it. > > 2) On slide of pros and cons of "small", all the "cons" are wrong as > > follows. > > > 2.1) Work with unaggregatable MAC namespace > > or break autoconfiguration > > > Structured ID can be autoconfigured by DHCP. > > DHCP doesn't exist (yet) in IPv6. Wrong. What does not exist in IPv6 is useful definition of autoconfiguration. > And for good reason: it is very hard > to operate this in a useful way. It is merely that it is very hard to operate IPv6 autoconfiguration in a useful way. But, that is not my problem. > > 2.2) Can't trust incoming id-loc association > > > Association between an ID and locators is secure if they > > are contained in a single packet. > > So if I call you and say my name is George W. Bush and give you my > phone number, you believe the mapping between Bush' identity and my > phone number is correct because it all happened in one exchange? Not at all. Instead, mapping between a phone number as an ID and a phone number as a locator is secure. Masataka Ohta. From owner-multi6@ops.ietf.org Thu Jul 24 19:49:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06270 for ; Thu, 24 Jul 2003 19:49:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fppX-000GNb-B2 for multi6-data@psg.com; Thu, 24 Jul 2003 23:49:03 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fppU-000GNO-Py for multi6@ops.ietf.org; Thu, 24 Jul 2003 23:49:01 +0000 From: Masataka Ohta Message-Id: <200307242340.IAA08535@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA08535; Fri, 25 Jul 2003 08:40:22 +0900 Subject: Re: Fwd: Minutes / Notes In-Reply-To: from Christian Huitema at "Jul 24, 2003 04:31:20 pm" To: Christian Huitema Date: Fri, 25 Jul 2003 08:40:21 +0859 () CC: Eliot Lear , "J. Noel Chiappa" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Christian; > That's why I was mentioning a virtual address rather than an HA. Are you > familiar with the distributed hash table algorithms? Basically, a DHT is > a reliable overlay on top of an arbitrary network. In a classic DHT > design, nodes have identifiers randomly spread in a large number space. > They maintain "routing tables" that allow them to forward a request for > a given number to the host most likely to know about it, etc. The common > trade-off is to have routing tables that scale as the logarithm of the > size of the network (O(log N)), while the number of relays required to > reach a specific destination also scales as O(log N). The routing table > would contain the current addresses/locators associated with the > identifier. Feel free to call it IPv7. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jul 24 20:13:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06615 for ; Thu, 24 Jul 2003 20:13:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fqBd-000IGC-Vq for multi6-data@psg.com; Fri, 25 Jul 2003 00:11:53 +0000 Received: from [160.36.58.43] (helo=astro.cs.utk.edu) by psg.com with esmtp (Exim 4.14) id 19fqBb-000IFw-Cm for multi6@ops.ietf.org; Fri, 25 Jul 2003 00:11:51 +0000 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6P0AQJ18372; Thu, 24 Jul 2003 20:10:28 -0400 (EDT) Date: Thu, 24 Jul 2003 20:10:26 -0400 From: Keith Moore To: Eliot Lear Cc: moore@cs.utk.edu, huitema@windows.microsoft.com, sbwoodside@yahoo.com, multi6@ops.ietf.org Subject: Re: Minutes / Notes Message-Id: <20030724201026.3ae5f884.moore@cs.utk.edu> In-Reply-To: <3F206F97.4030704@cisco.com> References: <3F20632C.9040507@cisco.com> <20030724185655.687d6468.moore@cs.utk.edu> <3F206F97.4030704@cisco.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The example Christian sited is precisely what is addressed in that > draft at one point. Perhaps what is bogus is your view of the draft. Perhaps what is bogus is the attempt to claim that that draft is representative of NSRG. From owner-multi6@ops.ietf.org Thu Jul 24 23:26:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10043 for ; Thu, 24 Jul 2003 23:26:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ftCH-0004aT-F5 for multi6-data@psg.com; Fri, 25 Jul 2003 03:24:45 +0000 Received: from [130.54.22.68] (helo=century.kuis.kyoto-u.ac.jp) by psg.com with esmtp (Exim 4.14) id 19ftCD-0004a4-KR for multi6@ops.ietf.org; Fri, 25 Jul 2003 03:24:41 +0000 Received: (qmail 13602 invoked by uid 0); 25 Jul 2003 12:24:23 +0900 Received: from century.kuis.kyoto-u.ac.jp (HELO bmdi2253.bmobile.ne.jp) (130.54.22.68) by century.kuis.kyoto-u.ac.jp with SMTP; 25 Jul 2003 12:24:23 +0900 Date: Fri, 25 Jul 2003 12:23:46 +0900 Message-ID: <3wu19bjnlp.wl@bmdi2253.bmobile.ne.jp> From: FUJIKAWA Kenji To: Masataka Ohta Cc: multi6@ops.ietf.org Subject: Re: Minutes / Notes In-Reply-To: <200307241154.UAA06500@necom830.hpcl.titech.ac.jp> References: <200307241154.UAA06500@necom830.hpcl.titech.ac.jp> User-Agent: Wanderlust/2.6.1 (Upside Down) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk At Thu, 24 Jul 2003 20:53:51 +0859 (), Masataka Ohta wrote: > > > 2.2) Can't trust incoming id-loc association > > > > > > Association between an ID and locators is secure if they > > > are contained in a single packet. > > Yes, it is. However, the following notification should be mentioned together. If ID/locator association is once established, the association cannot be changed without another checking mechanism, even when receiving a packet implying different association. ID/locator association should be managed in each connection separately if another checking mechanism is not provided. > > No. It is less secure than today usage of IP addresses (not talking about > > DNS) > > (see previous mail) > > It is as secure as the Internet today with an address binded both to > an ID and an locator. > --------------------------------------------------------------- FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan WWW: http://www.lab1.kuis.kyoto-u.ac.jp/~fujikawa/index-e.html TEL +81 75-753-5387 FAX +81 75-751-0482 E-mail fujikawa@real-internet.org From owner-multi6@ops.ietf.org Fri Jul 25 00:57:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11795 for ; Fri, 25 Jul 2003 00:57:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fucg-000Bhq-5Z for multi6-data@psg.com; Fri, 25 Jul 2003 04:56:06 +0000 Received: from [171.68.223.138] (helo=sj-core-4.cisco.com) by psg.com with esmtp (Exim 4.14) id 19fucc-000BdF-An for multi6@ops.ietf.org; Fri, 25 Jul 2003 04:56:02 +0000 Received: from cisco.com (sjc-vpn3-842.cisco.com [10.21.67.74]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6P4tOpp004258; Thu, 24 Jul 2003 21:55:24 -0700 (PDT) Message-ID: <3F20B83B.2080400@cisco.com> Date: Thu, 24 Jul 2003 21:55:23 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore CC: huitema@windows.microsoft.com, sbwoodside@yahoo.com, multi6@ops.ietf.org Subject: Re: Minutes / Notes References: <3F20632C.9040507@cisco.com> <20030724185655.687d6468.moore@cs.utk.edu> <3F206F97.4030704@cisco.com> <20030724201026.3ae5f884.moore@cs.utk.edu> In-Reply-To: <20030724201026.3ae5f884.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: > Perhaps what is bogus is the attempt to claim that that draft is > representative of NSRG. There is no such claim. Indeed just like this group there were different positions within the group that were not reconciled. Yours was one of them. Go back and read the draft. From owner-multi6@ops.ietf.org Fri Jul 25 01:39:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12447 for ; Fri, 25 Jul 2003 01:39:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fvHP-000Enh-PJ for multi6-data@psg.com; Fri, 25 Jul 2003 05:38:11 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19fvHM-000Egs-Qs for multi6@ops.ietf.org; Fri, 25 Jul 2003 05:38:09 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 307741C; Fri, 25 Jul 2003 08:47:15 +0300 (EEST) Message-ID: <3F20C221.6090407@nomadiclab.com> Date: Fri, 25 Jul 2003 08:37:37 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masataka Ohta Cc: multi6@ops.ietf.org Subject: Re: Fwd: Minutes / Notes References: <200307241728.CAA07568@necom830.hpcl.titech.ac.jp> In-Reply-To: <200307241728.CAA07568@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka Ohta wrote: >>>Yes, lacking proper acknowledgements from 131.112.32.132, the >>>peer will terminate the stream. >> >>Exactly. >> >>>That is, you can't send proper acknowledgements, unless you can >>>receive packets to 131.112.32.132, which is the return routability. >> >>Not true. If you open a TCP session and receive the first >>few packets, it is easy enough to generate fake ACKs. > > Assuming that there is no packet losses and that the attacker > send acks slowly enough, maybe. The attacker doesn't need to send the acks very slowly. See Stefan Savage, Neal Cardwell, David Wetherall, and Tom Anderson, "TCP Congestion Control with a Misbehaving Receiver", CCR, 1999. Note especially that after some initial data stream, the attacker can ignore incoming data (attack 3). --Pekka Nikander From owner-multi6@ops.ietf.org Fri Jul 25 01:51:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12835 for ; Fri, 25 Jul 2003 01:51:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fvSp-000FlU-8x for multi6-data@psg.com; Fri, 25 Jul 2003 05:49:59 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19fvSm-000Fl3-Ll for multi6@ops.ietf.org; Fri, 25 Jul 2003 05:49:56 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 49F261C; Fri, 25 Jul 2003 08:59:03 +0300 (EEST) Message-ID: <3F20C4E5.50001@nomadiclab.com> Date: Fri, 25 Jul 2003 08:49:25 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masataka Ohta Cc: marcelo bagnulo , multi6@ops.ietf.org Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes / Notes) References: <200307241711.CAA07345@necom830.hpcl.titech.ac.jp> In-Reply-To: <200307241711.CAA07345@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ohta-san, As so many times before, I am getting tired, since this discussion is getting more or less ridiculous. But that may be my fault, of course. >>>>The id/loc mapping itself needs some kind of protection, >>> >>>For most mapping, cookie is the protection. >>>For mobility mapping, the protection should use shared secret. >> >>Depending on the definition of cookie, I may agree. >>Depending on how you get the shared secret, I may agree. >> >>Hence, please be more specific. And please explain in >>detail how you *bootstrap* the system. > > It is of course that cookie is exchanged with three way handshake > and the shared secret is shared OOB. It is good that you think that we need a 3-way handshake for a cookie. There we may agree. Assuming a shared secret, exchanged OOB, between any two arbitrary hosts in the Internet, is, well, interesting. But apparently you are not claiming that. > Note that the shared secret is necessary only between HA and > MH (rest is done by cookie) that the secret is shared when > MH owner asks HA service to the administrator of the HA and > configured to MH when a HA address is configured. What is a HA in a multi-homing situation? Are you assuming some kind of infrastructure at the Internet, i.e. outside of the multi-homed network? If so, you open up the space for zillions of interesting solutions, most of which have very interesting single-point-of-failures or bottlenecks. And even in the simple case bootstrapping the shared secret between the multi-homed host and the infrastructure may turn out much more challenging than what you seem to assume. --Pekka From owner-multi6@ops.ietf.org Fri Jul 25 01:58:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12959 for ; Fri, 25 Jul 2003 01:58:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fvZh-000GSR-LE for multi6-data@psg.com; Fri, 25 Jul 2003 05:57:05 +0000 Received: from [212.181.227.13] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.14) id 19fvZO-000GOW-5Q for multi6@ops.ietf.org; Fri, 25 Jul 2003 05:56:46 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6P5tJFJ004752; Fri, 25 Jul 2003 07:56:00 +0200 (CEST) Date: Fri, 25 Jul 2003 07:18:31 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: marcelo bagnulo , Pekka Nikander , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200307241144.UAA06414@necom830.hpcl.titech.ac.jp> Message-Id: <6E3509D2-BE5F-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-20.4 required=5.0 tests=BAYES_10,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, UPPERCASE_25_50,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ohta-san, > I am aware that some people are stupid enough to believe it possible. This is not a very professional remark, actually quite the opposite. Please try and keep this discussion on a professional level. Everyone have their right to their view, even if that is not in line with what you think. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyC9qqarNKXTPFCVEQL8ngCeItnZ1jISy5Jjg6tQIZ8OAcXbRKUAoOjy yWwlSyQlP9OiAwCahBsLhKvS =fTGz -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Fri Jul 25 01:58:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12978 for ; Fri, 25 Jul 2003 01:58:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fva5-000GUp-MW for multi6-data@psg.com; Fri, 25 Jul 2003 05:57:29 +0000 Received: from [212.181.227.13] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.14) id 19fva1-000GUM-Ug for multi6@ops.ietf.org; Fri, 25 Jul 2003 05:57:27 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6P5unFJ004768; Fri, 25 Jul 2003 07:56:58 +0200 (CEST) Date: Fri, 25 Jul 2003 07:21:59 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: marcelo bagnulo , Iljitsch van Beijnum , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200307241154.UAA06500@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> I guess Iljitsch was talking about stateless autoconfig RFC 2462 > > RFC2462 does not give any useful definition of autoconfiguration. > > For example, in DNSOP WG, people, including those of IPv6 ones, > are discussing autoconfiguration with DHCP. Yes. But in the meeting it was pointed out after your question that this was referring to the features described in 2462. > >>> 2.2) Can't trust incoming id-loc association >>> >>> Association between an ID and locators is secure if they >>> are contained in a single packet. >> >> No. It is less secure than today usage of IP addresses (not talking >> about >> DNS) >> (see previous mail) > > It is as secure as the Internet today with an address binded both to > an ID and an locator. a) I don't think that maintaining the security level of todays Internet is a goal b) Introducing loc / id separation will require mapping, one way or the other. Even in LIN6 there is mapping between the layers. This introduces new bindings that needs to be secured. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyC+eqarNKXTPFCVEQK6lACg+vcEO9xMJYQZsVsqWchrCYbYA1YAn2aw LOkWTwMscD1e9LliIt6vBds0 =AXuj -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Fri Jul 25 02:01:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14034 for ; Fri, 25 Jul 2003 02:01:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fvd1-000Gox-Gy for multi6-data@psg.com; Fri, 25 Jul 2003 06:00:31 +0000 Received: from [212.181.227.13] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.14) id 19fvcw-000GoP-D2 for multi6@ops.ietf.org; Fri, 25 Jul 2003 06:00:29 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6P60AFJ004783; Fri, 25 Jul 2003 08:00:13 +0200 (CEST) Date: Fri, 25 Jul 2003 08:00:04 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Iljitsch van Beijnum , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200307242335.IAA08506@necom830.hpcl.titech.ac.jp> Message-Id: <3C2B9093-BE65-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-34.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REPLY_WITH_QUOTES, UPPERCASE_25_50,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On fredag, jul 25, 2003, at 01:36 Europe/Stockholm, Masataka Ohta wrote: >> >> DHCP doesn't exist (yet) in IPv6. > > Wrong. AFAIK there is no published standard for DHVPv6 > > What does not exist in IPv6 is useful definition of autoconfiguration. Noone is arguing against you. It's just that the rest of us are talking about a very specific case of autoconfiguration. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyDHZ6arNKXTPFCVEQLv4ACglmRgrDhl016UM3eFuoMJIeC8S4IAoOjZ rE+ua7aSX9WYbdzoKTkd2ZKA =88jJ -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Fri Jul 25 02:03:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16834 for ; Fri, 25 Jul 2003 02:03:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fvfN-000H6e-Ih for multi6-data@psg.com; Fri, 25 Jul 2003 06:02:57 +0000 Received: from [212.181.227.13] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.14) id 19fvfJ-000H6E-QA for multi6@ops.ietf.org; Fri, 25 Jul 2003 06:02:54 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6P62QFJ004797; Fri, 25 Jul 2003 08:02:26 +0200 (CEST) Date: Fri, 25 Jul 2003 08:02:18 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Eliot Lear , Keith Moore From: Kurt Erik Lindqvist In-Reply-To: <3F20B83B.2080400@cisco.com> Message-Id: <8C76A7C4-BE65-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Perhaps what is bogus is the attempt to claim that that draft is >> representative of NSRG. > > There is no such claim. Indeed just like this group there were > different positions within the group that were not reconciled. Yours > was one of them. Go back and read the draft. Could we please keep this discussion to things relevant to multi6? Disagreements in other forums is out of scope. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyDH76arNKXTPFCVEQKbyQCbBDTNK+cqMow5RUDpJocD0/Kp7E4An1jB Q/f3u7zdpBk8nhnc3KaM32Im =0d9t -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Fri Jul 25 02:21:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25598 for ; Fri, 25 Jul 2003 02:21:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fvws-000Ic7-KZ for multi6-data@psg.com; Fri, 25 Jul 2003 06:21:02 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19fvwo-000IXy-J5 for multi6@ops.ietf.org; Fri, 25 Jul 2003 06:20:58 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 15A711C; Fri, 25 Jul 2003 09:30:04 +0300 (EEST) Message-ID: <3F20CC2A.4030809@nomadiclab.com> Date: Fri, 25 Jul 2003 09:20:26 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo Cc: multi6@ops.ietf.org Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-31.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marcelo, >>Allowing an unprotected packet to set up or change >>identifier -> locator mapping seems to be dangerous. > > If this is dangerous, a possibility is to use some sort of crypto for each > node that you are communicating with in order to perform the binding. the > other possibility is some sort of RR check, as you mention below. Other > choices? I am not aware of other possibilities, but of course there may be others. What comes to crypto binding, I am only aware of two possibilities: Using asymmetric keys (or something similar) as primary identifiers, or using CGA (or something similar). All the other solutions that I know about require some kind of infrastructure, some kind of an enrollment procedure, or both. CGA is encumbered with IPRs, as we know. Using public keys as primary identifiers is basically HIP. Of course, you can design the exact details to be fairly different from what HIP currently is, but it is most probably very hard to do without a kind of four-way handshake without opening serious DoS vulnerabilities. > The problem with RR check is that it has to be done periodically in order to > prevent time shifting attacks. However, in the multi-homed case, perhaps > this could be avoided. I mean, an important difference between mobility and > multi-homing is that in multi-homing all the possible addresses are known in > advance. Hmm. Good points. The real question is whether the verifying peer is able to make a distinction between a mobility and multi-homing situation. That is, if there is a real multi-homed host, it probably has a set of fairly stable addresses. However, there might be an attacker that has a transient address but that claims that the transient address is one of its stable addresses. If it is able to convince the verifying party that the transient address is a stable address, that seems to open up time shifting attacks. --Pekka Nikander From owner-multi6@ops.ietf.org Fri Jul 25 04:30:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28748 for ; Fri, 25 Jul 2003 04:30:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fxwc-0002Xs-0d for multi6-data@psg.com; Fri, 25 Jul 2003 08:28:54 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fxwV-0002XY-NI for multi6@ops.ietf.org; Fri, 25 Jul 2003 08:28:48 +0000 From: Masataka Ohta Message-Id: <200307250817.RAA10390@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA10390; Fri, 25 Jul 2003 17:16:54 +0859 Subject: Re: Fwd: Minutes / Notes In-Reply-To: <3F20C221.6090407@nomadiclab.com> from Pekka Nikander at "Jul 25, 2003 08:37:37 am" To: Pekka Nikander Date: Fri, 25 Jul 2003 17:16:53 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-11.9 required=5.0 tests=BAYES_10,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka Nikander; > > Assuming that there is no packet losses and that the attacker > > send acks slowly enough, maybe. > > The attacker doesn't need to send the acks very slowly. See Yes, it does. > Stefan Savage, Neal Cardwell, David Wetherall, and Tom Anderson, > "TCP Congestion Control with a Misbehaving Receiver", > CCR, 1999. > > Note especially that after some initial data stream, > the attacker can ignore incoming data (attack 3). Wrong. As the paper says: Moreover, if an ACK arrives for data that has not yet been sent, this is generally ignored by the sending TCP the attacker must be able to know the current sequence number of a sender and reply ACKs with a sequence number a little more than that, or the ACKs are ignored. That is, the attacker should send ACKs slowly enough not to exceed the sequence number currently used by the sender. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jul 25 04:39:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28878 for ; Fri, 25 Jul 2003 04:39:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fy6O-0003Gh-BD for multi6-data@psg.com; Fri, 25 Jul 2003 08:39:00 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fy6L-0003GT-F4 for multi6@ops.ietf.org; Fri, 25 Jul 2003 08:38:57 +0000 From: Masataka Ohta Message-Id: <200307250825.RAA10440@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA10440; Fri, 25 Jul 2003 17:25:15 +0900 Subject: Re: Minutes / Notes In-Reply-To: <6E3509D2-BE5F-11D7-958B-000393A638B2@kurtis.pp.se> from Kurt Erik Lindqvist at "Jul 25, 2003 07:18:31 am" To: Kurt Erik Lindqvist Date: Fri, 25 Jul 2003 17:25:14 +0859 () CC: marcelo bagnulo , Pekka Nikander , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; Could you quote with more context? > > I am aware that some people are stupid enough to believe it possible. > > This is not a very professional remark, actually quite the opposite. It is a remark on people observed in other WG believing in autoconfigured security. As my remark continued, HIP, for example, does not assume so. On the other hand, statement like: > Date: Wed, 16 Jul 2003 14:58:45 +0200 > Subject: More random and not so random thoughts > From: Iljitsch van Beijnum > Message-Id: <3BB28B4C-B78D-11D7-9CB7-00039388672E@muada.com> > About the roadmap/more desing teams thing: I'm afraid of a situation > where a good core idea doesn't take some limitations in consideration > so the resulting proposal is flawed. It looks like this is already the > case with e2e/lin6, is not a very professional remark, actually quite the opposite, because it is a unfounded and weak remark contributing nothing constructive. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jul 25 04:50:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29073 for ; Fri, 25 Jul 2003 04:50:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fyGJ-0004A3-0Y for multi6-data@psg.com; Fri, 25 Jul 2003 08:49:15 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19fyGG-00045i-Pq for multi6@ops.ietf.org; Fri, 25 Jul 2003 08:49:12 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 868141C; Fri, 25 Jul 2003 11:58:19 +0300 (EEST) Message-ID: <3F20EEE9.4030607@nomadiclab.com> Date: Fri, 25 Jul 2003 11:48:41 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masataka Ohta Cc: multi6@ops.ietf.org Subject: Re: Fwd: Minutes / Notes References: <200307250817.RAA10390@necom830.hpcl.titech.ac.jp> In-Reply-To: <200307250817.RAA10390@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka Ohta wrote: >>>Assuming that there is no packet losses and that the attacker >>>send acks slowly enough, maybe. >> >>The attacker doesn't need to send the acks very slowly. See > > Yes, it does. ... > the attacker must be able to know the current sequence number of > a sender and reply ACKs with a sequence number a little more > than that, or the ACKs are ignored. Exactly. > > That is, the attacker should send ACKs slowly enough not to > exceed the sequence number currently used by the sender. Right, but that is not very slowly. Indeed, it may induce a faster data rate from the sender than the receiver is able to receive. --Pekka Nikander From owner-multi6@ops.ietf.org Fri Jul 25 04:50:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29150 for ; Fri, 25 Jul 2003 04:50:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fyG4-00046J-GP for multi6-data@psg.com; Fri, 25 Jul 2003 08:49:00 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fyG1-000463-Tz for multi6@ops.ietf.org; Fri, 25 Jul 2003 08:48:58 +0000 From: Masataka Ohta Message-Id: <200307250834.RAA10483@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA10483; Fri, 25 Jul 2003 17:33:59 +0859 Subject: Re: Minutes / Notes In-Reply-To: from Kurt Erik Lindqvist at "Jul 25, 2003 07:21:59 am" To: Kurt Erik Lindqvist Date: Fri, 25 Jul 2003 17:33:58 +0859 () CC: marcelo bagnulo , Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >> I guess Iljitsch was talking about stateless autoconfig RFC 2462 > > > > RFC2462 does not give any useful definition of autoconfiguration. > > > > For example, in DNSOP WG, people, including those of IPv6 ones, > > are discussing autoconfiguration with DHCP. > > Yes. But in the meeting it was pointed out after your question that > this was referring to the features described in 2462. And, then, it was pointed out that RFC 2462 is useless to define autoconfiguration. > > It is as secure as the Internet today with an address binded both to > > an ID and an locator. > > a) I don't think that maintaining the security level of todays Internet > is a goal I have never seen such requirement nor proposal. Note, for example, that HIP, having no cryptographic security on initial identity, merely maintains the security level of todays Internet. > b) Introducing loc / id separation will require mapping, one way or the > other. Wrong. The separation requires that a host know id and locators of its peer with reasonable security. > Even in LIN6 there is mapping between the layers. It's LIN6 mobility. > This introduces new bindings that needs to be secured. The separation requires that a host know id and locators of its peer with reasonable security. An initial packet of a connection containing all of them is just secure. LIN6 mobility, of course, needs other forms of security. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jul 25 04:59:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29392 for ; Fri, 25 Jul 2003 04:59:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fyPh-0004xi-Uz for multi6-data@psg.com; Fri, 25 Jul 2003 08:58:57 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fyPe-0004xK-DE for multi6@ops.ietf.org; Fri, 25 Jul 2003 08:58:54 +0000 From: Masataka Ohta Message-Id: <200307250846.RAA10531@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA10531; Fri, 25 Jul 2003 17:45:51 +0859 Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes / Notes) In-Reply-To: <3F20C4E5.50001@nomadiclab.com> from Pekka Nikander at "Jul 25, 2003 08:49:25 am" To: Pekka Nikander Date: Fri, 25 Jul 2003 17:45:51 +0859 () CC: marcelo bagnulo , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka; > As so many times before, I am getting tired, since > this discussion is getting more or less ridiculous. > But that may be my fault, of course. That, seemingly, is because you are agreeing with me. > > It is of course that cookie is exchanged with three way handshake > > and the shared secret is shared OOB. > > It is good that you think that we need a 3-way handshake > for a cookie. There we may agree. > > Assuming a shared secret, exchanged OOB, between any two > arbitrary hosts in the Internet, is, well, interesting. > But apparently you are not claiming that. So, there is no disagreement. > > Note that the shared secret is necessary only between HA and > > MH (rest is done by cookie) that the secret is shared when > > MH owner asks HA service to the administrator of the HA and > > configured to MH when a HA address is configured. > > What is a HA in a multi-homing situation? Good question. > Are you assuming > some kind of infrastructure at the Internet, i.e. outside > of the multi-homed network? Not at all. HA is a server serving mobile hosts. As is stated in my presentation of e2emh: IPv4 home agent is an end system provided by end users, just as WWW servers Foreign agent is intelligence in the network HA is an end system, a server host, and does not belong to an infrastructure of the Internet, just as WWW servers does not belong to the infrastructure. Thus, HA in a multi-homed site, of course, have multiple locators. In addition, a mobile host may be served by multiple HAs. It is already designed, implemented and running. > If so, you open up the space > for zillions of interesting solutions, most of which have > very interesting single-point-of-failures or bottlenecks. > And even in the simple case bootstrapping the shared secret > between the multi-homed host and the infrastructure may > turn out much more challenging than what you seem to assume. So, there is no disagreement. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jul 25 05:10:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29706 for ; Fri, 25 Jul 2003 05:10:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fyZJ-0005tZ-3i for multi6-data@psg.com; Fri, 25 Jul 2003 09:08:53 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fyZG-0005tL-Gg for multi6@ops.ietf.org; Fri, 25 Jul 2003 09:08:50 +0000 From: Masataka Ohta Message-Id: <200307250859.RAA10616@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA10616; Fri, 25 Jul 2003 17:59:27 +0900 Subject: Re: Fwd: Minutes / Notes In-Reply-To: <3F20EEE9.4030607@nomadiclab.com> from Pekka Nikander at "Jul 25, 2003 11:48:41 am" To: Pekka Nikander Date: Fri, 25 Jul 2003 17:59:27 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka; > >>>Assuming that there is no packet losses and that the attacker > >>>send acks slowly enough, maybe. > > That is, the attacker should send ACKs slowly enough not to > > exceed the sequence number currently used by the sender. > Right, but that is not very slowly. I never said "very slowly", though the attacker should behave conservatively to keep the attack continuing. > Indeed, it may induce > a faster data rate from the sender than the receiver is > able to receive. As I said, there is no "receiver", a host with ID XXX. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jul 25 05:10:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29735 for ; Fri, 25 Jul 2003 05:10:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fyZT-0005uj-Oy for multi6-data@psg.com; Fri, 25 Jul 2003 09:09:03 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19fyZQ-0005td-8T for multi6@ops.ietf.org; Fri, 25 Jul 2003 09:09:00 +0000 From: Masataka Ohta Message-Id: <200307250852.RAA10592@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA10592; Fri, 25 Jul 2003 17:52:12 +0900 Subject: Re: Minutes / Notes In-Reply-To: <3C2B9093-BE65-11D7-958B-000393A638B2@kurtis.pp.se> from Kurt Erik Lindqvist at "Jul 25, 2003 08:00:04 am" To: Kurt Erik Lindqvist Date: Fri, 25 Jul 2003 17:52:12 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >> DHCP doesn't exist (yet) in IPv6. > > > > Wrong. > > AFAIK there is no published standard for DHVPv6 And there is no published standard for LIN6, though LIN6 does exist in IPv6. It should be noted that people working on IPv6 autoconfiguration now assumes DHCPv6. > > What does not exist in IPv6 is useful definition of autoconfiguration. > > Noone is arguing against you. It's just that the rest of us are talking > about a very specific case of autoconfiguration. The problem is that there is no clear definition given on the autoconfiguration neither by IPv6 RFCs nor by those who claims to be talking about a very specific case of autoconfiguration. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jul 25 05:13:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29819 for ; Fri, 25 Jul 2003 05:13:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fyca-0006FR-CZ for multi6-data@psg.com; Fri, 25 Jul 2003 09:12:16 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19fycX-0006FE-9y for multi6@ops.ietf.org; Fri, 25 Jul 2003 09:12:13 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6P9CnxS084980; Fri, 25 Jul 2003 11:12:49 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 25 Jul 2003 11:12:10 +0200 Subject: Re: distributed hash tables Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Christian Huitema" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <1232FC57-BE80-11D7-B006-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, jul 25, 2003, at 01:31 Europe/Amsterdam, Christian Huitema wrote: >> What do you do when the network hosting your HA drops dead? > That's why I was mentioning a virtual address rather than an HA. Are > you > familiar with the distributed hash table algorithms? Basically, a DHT > is > a reliable overlay on top of an arbitrary network. In a classic DHT > design, nodes have identifiers randomly spread in a large number space. If you can distribute your information over a set of reliable and trustworthy nodes, this could work very well. However, we can't assume any one node to be reliable, so we need to build in a good deal of redundancy and dynamic replication. This also means that a resolver may need to contact several nodes in sequence to find the required information. But it gets worse: a node that is supposed to hold a certain piece of information could, rather than hand over the requested information, claim that the information doesn't exist. The only way that I can see to get around this is distribute copies of the same piece of information over so many nodes that it becomes infeasible to corrupt them all. Which probably means there isn't a workable tradeoff between security/reliability and performance. So essentially this has all the downsides of DNS and then some, with the only advantage that you now get to search in flat spaces too. From owner-multi6@ops.ietf.org Fri Jul 25 05:19:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29914 for ; Fri, 25 Jul 2003 05:19:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fyiZ-0006kR-Ii for multi6-data@psg.com; Fri, 25 Jul 2003 09:18:27 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19fyiW-0006k7-NV for multi6@ops.ietf.org; Fri, 25 Jul 2003 09:18:25 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6P9IuxS085039; Fri, 25 Jul 2003 11:18:56 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 25 Jul 2003 11:18:17 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Iljitsch van Beijnum In-Reply-To: <200307250852.RAA10592@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, jul 25, 2003, at 10:53 Europe/Amsterdam, Masataka Ohta wrote: > It should be noted that people working on IPv6 autoconfiguration > now assumes DHCPv6. They should talk to some operations people. After living without DHCP in IPv6, I doubt very many people want to go back to having to configure all this stuff on servers rather than having it happen automatically. From owner-multi6@ops.ietf.org Fri Jul 25 05:44:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00269 for ; Fri, 25 Jul 2003 05:44:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fz5r-0008ik-Tz for multi6-data@psg.com; Fri, 25 Jul 2003 09:42:31 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.14) id 19fz5p-0008iX-C5 for multi6@ops.ietf.org; Fri, 25 Jul 2003 09:42:29 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA10028 for ; Fri, 25 Jul 2003 10:42:27 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id KAA01239 for ; Fri, 25 Jul 2003 10:42:27 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6P9gR729223 for multi6@ops.ietf.org; Fri, 25 Jul 2003 10:42:27 +0100 Date: Fri, 25 Jul 2003 10:42:27 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: Minutes / Notes Message-ID: <20030725094227.GQ27991@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <200307250852.RAA10592@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jul 25, 2003 at 11:18:17AM +0200, Iljitsch van Beijnum wrote: > On vrijdag, jul 25, 2003, at 10:53 Europe/Amsterdam, Masataka Ohta > wrote: > > >It should be noted that people working on IPv6 autoconfiguration > >now assumes DHCPv6. > > They should talk to some operations people. After living without DHCP > in IPv6, I doubt very many people want to go back to having to > configure all this stuff on servers rather than having it happen > automatically. I agree. But there is no automatic way to get DNS resolver info in IPv6. In all proposals to date, somewhere something needs to be configured, be it in a DHCPv6 (Lite) server, in a router sending the RAs, by setting up site local routing (though that seems dead :) or by Masataka's method (where the routing entry is configured). Tim From owner-multi6@ops.ietf.org Fri Jul 25 06:03:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00649 for ; Fri, 25 Jul 2003 06:02:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fzOA-000AOE-Ca for multi6-data@psg.com; Fri, 25 Jul 2003 10:01:26 +0000 Received: from [134.193.143.159] (helo=kc-msxproto2.kc.umkc.edu) by psg.com with esmtp (Exim 4.14) id 19fzO7-000AO2-R9 for multi6@ops.ietf.org; Fri, 25 Jul 2003 10:01:23 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Fri, 25 Jul 2003 05:01:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: distributed hash tables Date: Fri, 25 Jul 2003 05:01:22 -0500 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108043@KC-MAIL4.kc.umkc.edu> Thread-Topic: distributed hash tables Thread-Index: AcNSjmQXvfktl1OKQayT+tz4p3QWlwAANNHw From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "Iljitsch van Beijnum" , "Christian Huitema" Cc: X-OriginalArrivalTime: 25 Jul 2003 10:01:22.0922 (UTC) FILETIME=[B3F2F4A0:01C35293] X-Spam-Status: No, hits=-9.1 required=5.0 tests=BAYES_01,FROM_ENDS_IN_NUMS,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >> What do you do when the network hosting your HA drops dead? >> That's why I was mentioning a virtual address rather than=20 >> an HA. Are you familiar with the distributed hash table=20 >> algorithms? Basically, a DHT is a reliable overlay on top=20 >> of an arbitrary network. In a classic DHT design, nodes have=20 >> identifiers randomly spread in a large number space. > >If you can distribute your information over a set of reliable and=20 >trustworthy nodes, this could work very well. However, we can't assume=20 >any one node to be reliable, so we need to build in a good deal of=20 >redundancy and dynamic replication.=20 Yes. This is a problem with classic design of DHT. But, recently there are lot of DHT proposals in a byzantine environment (viceroy etc..)=20 > This also means that a resolver may need to contact several nodes=20 > in sequence to find the required information. But it gets worse: a=20 > node that is supposed to hold a certain piece of information could,=20 > rather than hand over the=20 >requested=20 >information, claim that the information doesn't exist. The only way=20 >that I can see to get around this is distribute copies of the same=20 >piece of information over so many nodes that it becomes infeasible to=20 >corrupt them all. Which probably means there isn't a workable tradeoff=20 >between security/reliability and performance. > >So essentially this has all the downsides of DNS and then some, with=20 >the only advantage that you now get to search in flat spaces too. It doesn't follow a hiearchical model. It is a flat space, but maps it to an external cartesian space for uniqueness and scalability. The DHT=20 proposals differ in the cartesian space design and the respective=20 algorithm.Also, there are proposals for total decentralization of DNS and semantic-free naming by employing DHT.=20 For a quick DHT reading, go through=20 Routing Algorithms for DHTs: Some Open Questions Sylvia Ratnasamy, Scott Shenker and Ion Stoica http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf and its references.=20 A lot of thinking have to be done before using DHT as standard = identifiers.=20 It can be used as an identifier for specific set of applications. But, I = agree with christian that, modern applications have certain options to = be=20 used as identifiers (SIP URI, http URL, P2P: DHT/GUID/etc). From owner-multi6@ops.ietf.org Fri Jul 25 06:22:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01078 for ; Fri, 25 Jul 2003 06:22:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fzhr-000C5x-9w for multi6-data@psg.com; Fri, 25 Jul 2003 10:21:47 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19fzho-000C5l-LZ for multi6@ops.ietf.org; Fri, 25 Jul 2003 10:21:45 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6PAM1xS085745; Fri, 25 Jul 2003 12:22:02 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 25 Jul 2003 12:21:25 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Tim Chown From: Iljitsch van Beijnum In-Reply-To: <20030725094227.GQ27991@login.ecs.soton.ac.uk> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, jul 25, 2003, at 11:42 Europe/Amsterdam, Tim Chown wrote: > But there is no automatic way to get DNS resolver info in IPv6. > In all proposals to date, somewhere something needs to be configured, > be it in a DHCPv6 (Lite) server, in a router sending the RAs, by > setting > up site local routing (though that seems dead :) or by Masataka's > method > (where the routing entry is configured). If you think about it, having to find an address for a server that helps you find addresses is somehwat bizarre... I think it makes much more sense to hardcode these addresses in the OS (should be possible to override by the administrator of course). This goes both for the root servers which of course need regular address space and for on-site resolvers which then need site local addresses. So I guess we have a good use for site local addresses after all. From owner-multi6@ops.ietf.org Fri Jul 25 07:10:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01959 for ; Fri, 25 Jul 2003 07:10:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19g0RT-000FuH-JD for multi6-data@psg.com; Fri, 25 Jul 2003 11:08:55 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19g0RQ-000Fu4-S2 for multi6@ops.ietf.org; Fri, 25 Jul 2003 11:08:53 +0000 From: Masataka Ohta Message-Id: <200307251102.UAA11551@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA11551; Fri, 25 Jul 2003 20:02:09 +0900 Subject: Re: Minutes / Notes In-Reply-To: from Iljitsch van Beijnum at "Jul 25, 2003 12:21:25 pm" To: Iljitsch van Beijnum Date: Fri, 25 Jul 2003 20:02:07 +0859 () CC: Tim Chown , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > > But there is no automatic way to get DNS resolver info in IPv6. > > > In all proposals to date, somewhere something needs to be configured, > > be it in a DHCPv6 (Lite) server, in a router sending the RAs, by > > setting > > up site local routing (though that seems dead :) or by Masataka's > > method > > (where the routing entry is configured). > > If you think about it, having to find an address for a server that > helps you find addresses is somehwat bizarre... Not so much. It becomes really bizarre, when people start requesting autoconfiguration of a lot more than that such as DNS dynamic update which naturally requires configured shared secret. > I think it makes much > more sense to hardcode these addresses in the OS (should be possible to > override by the administrator of course). FYI, that's my proposal to appear as draft-ohta-preconfigured-dns-00.txt, though you misunderstand the important detail. > This goes both for the root > servers which of course need regular address space You should be more aggressive for root servers, as I described in a separated ID. > and for on-site resolvers which then need site local addresses. > So I guess we have a > good use for site local addresses after all. No, scoped addresses make the proposal poor. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jul 25 07:29:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02204 for ; Fri, 25 Jul 2003 07:29:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19g0ki-000HMZ-Kn for multi6-data@psg.com; Fri, 25 Jul 2003 11:28:48 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19g0kf-000HMM-Om for multi6@ops.ietf.org; Fri, 25 Jul 2003 11:28:46 +0000 From: Masataka Ohta Message-Id: <200307251116.UAA11598@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA11598; Fri, 25 Jul 2003 20:16:38 +0900 Subject: Re: Minutes / Notes In-Reply-To: <20030725094227.GQ27991@login.ecs.soton.ac.uk> from Tim Chown at "Jul 25, 2003 10:42:27 am" To: Tim Chown Date: Fri, 25 Jul 2003 20:16:37 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Tim; > > They should talk to some operations people. After living without DHCP > > in IPv6, I doubt very many people want to go back to having to > > configure all this stuff on servers rather than having it happen > > automatically. > > I agree. > > But there is no automatic way to get DNS resolver info in IPv6. Operational people MUST still configure all that stuff on DNS servers for their domain. Or, do you want to live without DNS? FYI, I was living without DNS in IPv4 that I don't want to do so with addresses four times (or more with multihoming) more lengthy. > In all proposals to date, somewhere something needs to be configured, > be it in a DHCPv6 (Lite) server, in a router sending the RAs, by setting > up site local routing (though that seems dead :) or by Masataka's method > (where the routing entry is configured). Recursive servers, of course, need SBELT information configured, unless fixed root server addresses are standardized. But, that's all. Recursive servers can be preconfigured too, by default, to have an anycast address to be advertised by some default routing protocol. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jul 25 09:37:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04572 for ; Fri, 25 Jul 2003 09:37:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19g2jE-000OOA-Df for multi6-data@psg.com; Fri, 25 Jul 2003 13:35:24 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19g2jA-000OLV-Tz for multi6@ops.ietf.org; Fri, 25 Jul 2003 13:35:21 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 724404330E; Fri, 25 Jul 2003 15:27:35 +0200 (CEST) Received: from lolo (unknown [163.117.139.224]) by smtp01.uc3m.es (Postfix) with SMTP id 00C9D99E5D; Fri, 25 Jul 2003 15:27:35 +0200 (CEST) From: "marcelo bagnulo" To: "Pekka Nikander" Cc: Subject: RE: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) Date: Fri, 25 Jul 2003 15:26:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3F20CC2A.4030809@nomadiclab.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Spam-Status: No, hits=-15.8 required=5.0 tests=BAYES_20,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Hmm. Good points. The real question is whether the verifying peer > is able to make a distinction between a mobility and multi-homing > situation. That is, if there is a real multi-homed host, it probably > has a set of fairly stable addresses. However, there might be an > attacker that has a transient address but that claims that the transient > address is one of its stable addresses. If it is able to convince > the verifying party that the transient address is a stable address, > that seems to open up time shifting attacks. Yes. However, the attack is only possible at the begining of the communication and it is not possible for the rest of the communication lifetime (which would be the mobility case) This is still less secure than regular IPv6 but the time that the nodes are exposed to attacks is much more limited. I do not know if this would be good enough, though. Regards, marcelo > > --Pekka Nikander > From owner-multi6@ops.ietf.org Fri Jul 25 10:32:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07597 for ; Fri, 25 Jul 2003 10:32:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19g3bB-00023N-8w for multi6-data@psg.com; Fri, 25 Jul 2003 14:31:09 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.14) id 19g3b8-00020Z-8r for multi6@ops.ietf.org; Fri, 25 Jul 2003 14:31:06 +0000 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 25 Jul 2003 07:32:12 -0700 Received: from cisco.com (sjc-vpn2-801.cisco.com [10.21.115.33]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6PEUXuG021782; Fri, 25 Jul 2003 07:30:33 -0700 (PDT) Message-ID: <3F213F08.3030905@cisco.com> Date: Fri, 25 Jul 2003 07:30:32 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Keith Moore , multi6@ops.ietf.org Subject: Re: Minutes / Notes References: <8C76A7C4-BE65-11D7-958B-000393A638B2@kurtis.pp.se> In-Reply-To: <8C76A7C4-BE65-11D7-958B-000393A638B2@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt Erik Lindqvist wrote: > > Could we please keep this discussion to things relevant to multi6? > Disagreements in other forums is out of scope. > The draft (draft-irtf-nsrg-report-09.txt) is relevant to multi6 and the current discussion. Eliot From owner-multi6@ops.ietf.org Fri Jul 25 14:13:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14144 for ; Fri, 25 Jul 2003 14:13:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19g72f-000Frf-Ji for multi6-data@psg.com; Fri, 25 Jul 2003 18:11:45 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19g72c-000FqS-Hg for multi6@ops.ietf.org; Fri, 25 Jul 2003 18:11:42 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 909651C; Fri, 25 Jul 2003 21:20:48 +0300 (EEST) Message-ID: <3F2172BF.2030403@nomadiclab.com> Date: Fri, 25 Jul 2003 21:11:11 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo Cc: multi6@ops.ietf.org Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: >>Hmm. Good points. The real question is whether the verifying peer >>is able to make a distinction between a mobility and multi-homing >>situation. That is, if there is a real multi-homed host, it probably >>has a set of fairly stable addresses. However, there might be an >>attacker that has a transient address but that claims that the transient >>address is one of its stable addresses. If it is able to convince >>the verifying party that the transient address is a stable address, >>that seems to open up time shifting attacks. > > Yes. However, the attack is only possible at the begining of the > communication and it is not possible for the rest of the communication > lifetime (which would be the mobility case) Right. However, the attacker is most probably able to select the most convenient time to initiate communication. Hence, I don't see this much changing the situation. > This is still less secure than regular IPv6 but the time that the nodes are > exposed to attacks is much more limited. I do not know if this would be good > enough, though. The real question is whether there are attacks against standard non-multi-homed hosts or flooding attacks against networks. It looks like there might be. I am starting to think that we would need a proper security analysis on multi-address multi-homing. I might be willing to spend some cycles on writing a draft on that, but only later in the fall (starting from mid September or so). --Pekka NIkander From owner-multi6@ops.ietf.org Fri Jul 25 15:31:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18176 for ; Fri, 25 Jul 2003 15:31:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19g8FY-000KLO-Bt for multi6-data@psg.com; Fri, 25 Jul 2003 19:29:08 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19g8FV-000KKy-0S for multi6@ops.ietf.org; Fri, 25 Jul 2003 19:29:05 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6PJTdxS091428; Fri, 25 Jul 2003 21:29:40 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 25 Jul 2003 20:34:37 +0200 Subject: Re: distributed hash tables Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Ayyasamy, Senthilkumar (UMKC-Student)" From: Iljitsch van Beijnum In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B01108043@KC-MAIL4.kc.umkc.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, jul 25, 2003, at 12:01 Europe/Amsterdam, Ayyasamy, Senthilkumar (UMKC-Student) wrote: >> If you can distribute your information over a set of reliable and >> trustworthy nodes, this could work very well. However, we can't assume >> any one node to be reliable, so we need to build in a good deal of >> redundancy and dynamic replication. > Yes. This is a problem with classic design of DHT. But, recently > there are lot of DHT proposals in a byzantine environment (viceroy > etc..) Hm, not easy to find anything on this but I can't think of any way to do better than have statistical assurances (i.e., 10 servers say it doesn't exist so it probably doesn't). Also, wouldn't the huge number of identifiers (order of a hundred million *today*) be a problem? Any given server would have to fit into the key space in very many places. From owner-multi6@ops.ietf.org Fri Jul 25 16:24:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22287 for ; Fri, 25 Jul 2003 16:24:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19g95q-000Nxj-0k for multi6-data@psg.com; Fri, 25 Jul 2003 20:23:10 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.14) id 19g95m-000NwZ-4r for multi6@ops.ietf.org; Fri, 25 Jul 2003 20:23:06 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id DC82734494; Fri, 25 Jul 2003 13:22:43 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6PKMVYB013738; Fri, 25 Jul 2003 13:22:31 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) Date: Fri, 25 Jul 2003 13:22:31 -0700 Message-ID: Thread-Topic: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) Thread-Index: AcNS2mqOw8z+71H2Rv+40wfABy/vuAAD/G3A From: "Tony Li" To: "Pekka Nikander" , "marcelo bagnulo" Cc: X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable | I am starting to think that we would need a proper security | analysis on multi-address multi-homing. I might be willing | to spend some cycles on writing a draft on that, but only | later in the fall (starting from mid September or so). Actually, we've already been able to draft Steve Bellovin to help us out here. Thanks for volunteering tho. Tony From owner-multi6@ops.ietf.org Mon Jul 28 04:11:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23044 for ; Mon, 28 Jul 2003 04:11:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19h31l-000227-Ma for multi6-data@psg.com; Mon, 28 Jul 2003 08:06:41 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.20) id 19h31g-00021U-Gt for multi6@ops.ietf.org; Mon, 28 Jul 2003 08:06:36 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 8BD5043276; Mon, 28 Jul 2003 10:06:35 +0200 (CEST) Received: from lolo (unknown [163.117.139.224]) by smtp01.uc3m.es (Postfix) with SMTP id 23F6099E73; Mon, 28 Jul 2003 10:06:35 +0200 (CEST) From: "marcelo bagnulo" To: "Pekka Nikander" Cc: Subject: RE: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) Date: Mon, 28 Jul 2003 10:04:58 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3F2172BF.2030403@nomadiclab.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Spam-Status: No, hits=-12.7 required=5.0 tests=IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Mensaje original----- > De: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Enviado el: viernes, 25 de julio de 2003 20:11 > Para: marcelo bagnulo > CC: multi6@ops.ietf.org > Asunto: Re: Reasonable to use crypto in all communications? (Re: Fwd: > Minutes/Notes) > > > marcelo bagnulo wrote: > >>Hmm. Good points. The real question is whether the verifying peer > >>is able to make a distinction between a mobility and multi-homing > >>situation. That is, if there is a real multi-homed host, it probably > >>has a set of fairly stable addresses. However, there might be an > >>attacker that has a transient address but that claims that the transient > >>address is one of its stable addresses. If it is able to convince > >>the verifying party that the transient address is a stable address, > >>that seems to open up time shifting attacks. > > > > Yes. However, the attack is only possible at the begining of the > > communication and it is not possible for the rest of the communication > > lifetime (which would be the mobility case) > > Right. However, the attacker is most probably able to select > the most convenient time to initiate communication. Hence, I don't > see this much changing the situation. I think there is an important difference. As you mention, the attacker can initiate a new communication whenever he wants, but he cannot hijack an already initiated communication, which would be possible in the mip scenario by just sending a BU in an existent communication. > > > This is still less secure than regular IPv6 but the time that > the nodes are > > exposed to attacks is much more limited. I do not know if this > would be good > > enough, though. > > The real question is whether there are attacks against standard > non-multi-homed hosts or flooding attacks against networks. > It looks like there might be. > > I am starting to think that we would need a proper security > analysis on multi-address multi-homing. I might be willing > to spend some cycles on writing a draft on that, but only > later in the fall (starting from mid September or so). > I think that this would be really usefull. I am willing to try to comment if you write something. Thanks, marcelo > --Pekka NIkander > > From owner-multi6@ops.ietf.org Mon Jul 28 11:16:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05787 for ; Mon, 28 Jul 2003 11:16:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19h9iZ-0003VG-9e for multi6-data@psg.com; Mon, 28 Jul 2003 15:15:19 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.20) id 19h9iV-0003V3-1S for multi6@ops.ietf.org; Mon, 28 Jul 2003 15:15:15 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6SFF17h000541; Mon, 28 Jul 2003 09:15:01 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6SFEvQ03411; Mon, 28 Jul 2003 17:14:57 +0200 (MEST) Date: Mon, 28 Jul 2003 17:12:49 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) To: Pekka Nikander Cc: marcelo bagnulo , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <3F2172BF.2030403@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > I am starting to think that we would need a proper security > analysis on multi-address multi-homing. I might be willing > to spend some cycles on writing a draft on that, but only > later in the fall (starting from mid September or so). I think that would be very useful. Erik From owner-multi6@ops.ietf.org Mon Jul 28 21:51:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27108 for ; Mon, 28 Jul 2003 21:51:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hJc9-000J2I-Ea for multi6-data@psg.com; Tue, 29 Jul 2003 01:49:21 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19hJc2-000J24-S2 for multi6@ops.ietf.org; Tue, 29 Jul 2003 01:49:15 +0000 From: Masataka Ohta Message-Id: <200307290135.KAA14418@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA14418; Tue, 29 Jul 2003 10:35:21 +0900 Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) In-Reply-To: from marcelo bagnulo at "Jul 28, 2003 10:04:58 am" To: marcelo bagnulo Date: Tue, 29 Jul 2003 10:35:20 +0859 () CC: Pekka Nikander , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-11.9 required=5.0 tests=BAYES_10,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Marcelo; > > > Yes. However, the attack is only possible at the begining of the > > > communication and it is not possible for the rest of the communication > > > lifetime (which would be the mobility case) > > > > Right. However, the attacker is most probably able to select > > the most convenient time to initiate communication. Hence, I don't > > see this much changing the situation. > > I think there is an important difference. As you mention, the attacker can > initiate a new communication whenever he wants, but he cannot hijack an > already initiated communication, which would be possible in the mip scenario > by just sending a BU in an existent communication. You are too optimistic. There is no meaningful difference. A reasonable attacker will act as a MITM always hijacking new communications. As the MITM relay them to legitimate peers most of the time, you won't notice the presense of MITM. Then, the attacker, at will, can suspend relaying and insert any forged data into an already initiated communication. > > I am starting to think that we would need a proper security > > analysis on multi-address multi-homing. So far, it is just a well known MITM attack no specific to multihoming. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jul 29 05:19:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16447 for ; Tue, 29 Jul 2003 05:19:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hQb8-000Ls0-Ga for multi6-data@psg.com; Tue, 29 Jul 2003 09:16:46 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.20) id 19hQb5-000LrH-FJ for multi6@ops.ietf.org; Tue, 29 Jul 2003 09:16:43 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id A4CC043179; Tue, 29 Jul 2003 11:16:42 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.224]) by smtp01.uc3m.es (Postfix) with SMTP id 0976F99E66; Tue, 29 Jul 2003 11:16:42 +0200 (CEST) From: "marcelo bagnulo" To: "Masataka Ohta" Cc: "Pekka Nikander" , Subject: RE: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) Date: Tue, 29 Jul 2003 11:15:02 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200307290135.KAA14418@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Spam-Status: No, hits=-19.3 required=5.0 tests=BAYES_01,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So far, it is just a well known MITM attack no specific to multihoming. Again, have you heard about time shifting attacks? This type of attack is not possible in regular IPv6 communications and multi-homing mechanisms can enable them. The same goes for some flooding attacks. But you still are not interested in reading Pekka' s draft, i guess :-( Regards, marcelo > > Masataka Ohta > From owner-multi6@ops.ietf.org Tue Jul 29 06:30:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17742 for ; Tue, 29 Jul 2003 06:30:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hRii-0001F0-P1 for multi6-data@psg.com; Tue, 29 Jul 2003 10:28:40 +0000 Received: from [192.71.80.74] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.20) id 19hRie-0001Ek-AZ for multi6@ops.ietf.org; Tue, 29 Jul 2003 10:28:36 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6TASIFJ006096; Tue, 29 Jul 2003 12:28:23 +0200 (CEST) Date: Tue, 29 Jul 2003 12:28:10 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: marcelo bagnulo , Iljitsch van Beijnum , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200307250834.RAA10483@necom830.hpcl.titech.ac.jp> Message-Id: <5A499F30-C1AF-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.6 required=5.0 tests=BAYES_10,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> I guess Iljitsch was talking about stateless autoconfig RFC 2462 >>> >>> RFC2462 does not give any useful definition of autoconfiguration. >>> >>> For example, in DNSOP WG, people, including those of IPv6 ones, >>> are discussing autoconfiguration with DHCP. >> >> Yes. But in the meeting it was pointed out after your question that >> this was referring to the features described in 2462. > > And, then, it was pointed out that RFC 2462 is useless to define > autoconfiguration. Noone said that 2462 gives the definition of autoconfiguration. We where talking about the technology described in 2462. > >>> It is as secure as the Internet today with an address binded both to >>> an ID and an locator. >> >> a) I don't think that maintaining the security level of todays >> Internet >> is a goal > > I have never seen such requirement nor proposal. I think that anything that can improve the security of todays Internet, tomorrows Internet and yesterdays Internet will be looked upon favorably. >> b) Introducing loc / id separation will require mapping, one way or >> the >> other. > > Wrong. The separation requires that a host know id and locators of > its peer with reasonable security. That is a mapping state in it self. >> This introduces new bindings that needs to be secured. > > The separation requires that a host know id and locators of its > peer with reasonable security. An initial packet of a connection > containing all of them is just secure. That is as secure as the trust relationship of the creator of the packet. > > - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyZMP6arNKXTPFCVEQJpUQCgtT/x4a8+T+GLdMfk1vcOx+9Co/kAn0np FSL6wFllcSejkkXXqFoO97eT =b2qd -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jul 29 06:31:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17822 for ; Tue, 29 Jul 2003 06:31:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hRkJ-0001Jt-6C for multi6-data@psg.com; Tue, 29 Jul 2003 10:30:19 +0000 Received: from [192.71.80.74] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.20) id 19hRkG-0001JI-SE for multi6@ops.ietf.org; Tue, 29 Jul 2003 10:30:17 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6TAUHFJ006099; Tue, 29 Jul 2003 12:30:17 +0200 (CEST) Date: Tue, 29 Jul 2003 12:30:12 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Iljitsch van Beijnum , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200307250852.RAA10592@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> DHCP doesn't exist (yet) in IPv6. >>> >>> Wrong. >> >> AFAIK there is no published standard for DHVPv6 > > And there is no published standard for LIN6, though LIN6 does > exist in IPv6. There are a lot of things that exists and that is related to IP, TCP, UDP and the Internet that is not standard. > It should be noted that people working on IPv6 autoconfiguration > now assumes DHCPv6. From what I have been reading people seems to be assuming DHCPv6 and 2462. >>> What does not exist in IPv6 is useful definition of >>> autoconfiguration. >> >> Noone is arguing against you. It's just that the rest of us are >> talking >> about a very specific case of autoconfiguration. > > The problem is that there is no clear definition given on the > autoconfiguration neither by IPv6 RFCs nor by those who claims > to be talking about a very specific case of autoconfiguration. Noone is arguing against you. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyZMtqarNKXTPFCVEQLhpQCg+/19iLp5eblvtIr0B84ZkZQDll8AnA3q Y63gjOeVo7xd5nPUGrs3KSdt =kqMo -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jul 29 07:01:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18299 for ; Tue, 29 Jul 2003 07:01:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hSDG-0004V4-PY for multi6-data@psg.com; Tue, 29 Jul 2003 11:00:14 +0000 Received: from [192.71.80.74] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.20) id 19hSDE-0004Uk-6O for multi6@ops.ietf.org; Tue, 29 Jul 2003 11:00:12 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6TAxpFJ006110; Tue, 29 Jul 2003 12:59:51 +0200 (CEST) Date: Tue, 29 Jul 2003 12:59:45 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: marcelo bagnulo , Pekka Nikander , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200307250825.RAA10440@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.6 required=5.0 tests=BAYES_10,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> I am aware that some people are stupid enough to believe it possible. >> >> This is not a very professional remark, actually quite the opposite. > > It is a remark on people observed in other WG believing in > autoconfigured security. As my remark continued, HIP, for > example, does not assume so. No, but you are attributing a view on the intelligence of people proposing a certain solution. This is what I am telling you to stop. > > On the other hand, statement like: > >> Date: Wed, 16 Jul 2003 14:58:45 +0200 >> Subject: More random and not so random thoughts >> From: Iljitsch van Beijnum >> Message-Id: <3BB28B4C-B78D-11D7-9CB7-00039388672E@muada.com> > >> About the roadmap/more desing teams thing: I'm afraid of a situation >> where a good core idea doesn't take some limitations in consideration >> so the resulting proposal is flawed. It looks like this is already the >> case with e2e/lin6, > > is not a very professional remark, actually quite the opposite, > because it is a unfounded and weak remark contributing nothing > constructive. > This does not attribute anything to anyone. It talks about a specific proposal. Please refrain from comments on other members of the WG. Feel free to argue over their proposals as long as you include reasoning for your own views. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyZTpKarNKXTPFCVEQLZBgCfa4+3q1Jlu/0SE0QEQlrd9/lm2h4AnisP uCubB9OfbXBcHf//xJz7nvAU =+cxD -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jul 29 07:04:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18323 for ; Tue, 29 Jul 2003 07:04:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hSFS-0004hO-44 for multi6-data@psg.com; Tue, 29 Jul 2003 11:02:30 +0000 Received: from [192.71.80.74] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.20) id 19hSFP-0004gR-Mt for multi6@ops.ietf.org; Tue, 29 Jul 2003 11:02:27 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6TB2QFJ006113; Tue, 29 Jul 2003 13:02:27 +0200 (CEST) Date: Tue, 29 Jul 2003 13:02:21 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Keith Moore , multi6@ops.ietf.org To: Eliot Lear From: Kurt Erik Lindqvist In-Reply-To: <3F213F08.3030905@cisco.com> Message-Id: <20CE7E6F-C1B4-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.2 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, UPPERCASE_25_50,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Could we please keep this discussion to things relevant to multi6? >> Disagreements in other forums is out of scope. > > The draft (draft-irtf-nsrg-report-09.txt) is relevant to multi6 and > the current discussion. Yes. But not the discussion on what was or wasn't said in another group. Discussions on the content and applicability in multi6, fine. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyZUQKarNKXTPFCVEQIECgCg8t7Wz+qEy9K4OGCEHGTmRxqHnT4AniBP otQ60ACcW44nJ48Hf/4hpdAJ =H8BK -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jul 29 07:12:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18432 for ; Tue, 29 Jul 2003 07:12:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hSOn-0005fQ-Eo for multi6-data@psg.com; Tue, 29 Jul 2003 11:12:09 +0000 Received: from [192.71.80.74] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.20) id 19hSOl-0005eu-6W for multi6@ops.ietf.org; Tue, 29 Jul 2003 11:12:07 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6TBC7FJ006120; Tue, 29 Jul 2003 13:12:08 +0200 (CEST) Date: Tue, 29 Jul 2003 13:12:01 +0200 Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Pekka Nikander" , "marcelo bagnulo" , To: "Tony Li" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <7A777879-C1B5-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony, > | I am starting to think that we would need a proper security > | analysis on multi-address multi-homing. I might be willing > | to spend some cycles on writing a draft on that, but only > | later in the fall (starting from mid September or so). > > > Actually, we've already been able to draft Steve Bellovin to help > us out here. Thanks for volunteering tho. > Are you saying that you will also present a draft on this, or are you saying that you have enlisted Steve for working with design-team-1 (for lack of better separation)? I think that a draft outlining security threats for multi-addressing would also be good, perhaps working with design-team-2? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyZWhKarNKXTPFCVEQKA/QCfXwfh4IeNBlzwopk2waAeiaeWqAAAoK0k bTOAvF2GAnESRwdCEIDPNXP+ =vSUl -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jul 29 07:19:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18734 for ; Tue, 29 Jul 2003 07:19:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hSVf-0006R6-88 for multi6-data@psg.com; Tue, 29 Jul 2003 11:19:15 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19hSVc-0006Ql-O6 for multi6@ops.ietf.org; Tue, 29 Jul 2003 11:19:13 +0000 From: Masataka Ohta Message-Id: <200307291105.UAA00541@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA00541; Tue, 29 Jul 2003 20:05:32 +0900 Subject: Re: Minutes / Notes In-Reply-To: <5A499F30-C1AF-11D7-958B-000393A638B2@kurtis.pp.se> from Kurt Erik Lindqvist at "Jul 29, 2003 12:28:10 pm" To: Kurt Erik Lindqvist Date: Tue, 29 Jul 2003 20:05:31 +0859 () CC: marcelo bagnulo , Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > >>>> I guess Iljitsch was talking about stateless autoconfig RFC 2462 > >>> > >>> RFC2462 does not give any useful definition of autoconfiguration. > >>> > >>> For example, in DNSOP WG, people, including those of IPv6 ones, > >>> are discussing autoconfiguration with DHCP. > >> > >> Yes. But in the meeting it was pointed out after your question that > >> this was referring to the features described in 2462. > > > > And, then, it was pointed out that RFC 2462 is useless to define > > autoconfiguration. > > Noone said that 2462 gives the definition of autoconfiguration. Wrong. My question is on definition of autoconfiguration of the presentation by Iljitsch. Iljitsch could not provide any answer. As I further asked, Erik said that 2462 gives the definition of the autoconfiguration of the presentation. And, then, it was pointed out that RFC 2462 is useless to define autoconfiguration. > I think that anything that can improve the security of todays Internet, > tomorrows Internet and yesterdays Internet will be looked upon > favorably. An abstract nonsense. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jul 29 07:30:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18933 for ; Tue, 29 Jul 2003 07:30:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hSfD-0007Sm-4x for multi6-data@psg.com; Tue, 29 Jul 2003 11:29:07 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19hSfA-0007SP-59 for multi6@ops.ietf.org; Tue, 29 Jul 2003 11:29:04 +0000 From: Masataka Ohta Message-Id: <200307291115.UAA00688@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA00688; Tue, 29 Jul 2003 20:15:30 +0900 Subject: Re: Minutes / Notes In-Reply-To: from Kurt Erik Lindqvist at "Jul 29, 2003 12:30:12 pm" To: Kurt Erik Lindqvist Date: Tue, 29 Jul 2003 20:15:30 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >> AFAIK there is no published standard for DHVPv6 > > > > And there is no published standard for LIN6, though LIN6 does > > exist in IPv6. > > There are a lot of things that exists and that is related to IP, TCP, > UDP and the Internet that is not standard. > > > It should be noted that people working on IPv6 autoconfiguration > > now assumes DHCPv6. > > From what I have been reading people seems to be assuming DHCPv6 and > 2462. Are you now saying DHCPv6 defined? If you are saying it defined, where, do you think, I can find your definition? From what I have been reading some people seems to be assuming DHCPv6 by ignoring 2462. Some other people seems to be simultaneously assuming both DHCPv6 and 2462 ignoring the contradiction between them. Masataka Ohta PS While I can continue the argument, others may not. As an expert on autoconfiguration issues, my advice on the WG is that multi6 WG should ignore autoconfiguration entirely unless useful definition of it could be defined by someone else. From owner-multi6@ops.ietf.org Tue Jul 29 07:37:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19147 for ; Tue, 29 Jul 2003 07:37:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hSn8-0008G1-4P for multi6-data@psg.com; Tue, 29 Jul 2003 11:37:18 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.20) id 19hSn6-0008Fp-7l for multi6@ops.ietf.org; Tue, 29 Jul 2003 11:37:16 +0000 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2003 04:39:53 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6TBbE89029232 for ; Tue, 29 Jul 2003 04:37:14 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn1-223.cisco.com [10.21.96.223]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABB29812; Tue, 29 Jul 2003 07:37:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20030729073128.04335408@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Jul 2003 07:34:47 -0400 To: multi6@ops.ietf.org From: Ralph Droms Subject: Re: Minutes / Notes In-Reply-To: <3C2B9093-BE65-11D7-958B-000393A638B2@kurtis.pp.se> References: <200307242335.IAA08506@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Technically, no, there is no published standard for DHCPv6 because the RFC isn't quite done. The authros have been integrating results form interoperability tests and correcting a couple of last bugs discovered during the authors 48 hour final review period. Practically speaking, the standard is sufficiently well-understood that there are several (at least six) implementations that have been successfully demonstrated interoperability in three rounds of open interoperability testing. - Ralph At 08:00 AM 7/25/2003 +0200, Kurt Erik Lindqvist wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >On fredag, jul 25, 2003, at 01:36 Europe/Stockholm, Masataka Ohta wrote: > > >> > >> DHCP doesn't exist (yet) in IPv6. > > > > Wrong. > >AFAIK there is no published standard for DHVPv6 > > > > > What does not exist in IPv6 is useful definition of autoconfiguration. > >Noone is arguing against you. It's just that the rest of us are talking >about a very specific case of autoconfiguration. > >- - kurtis - > >-----BEGIN PGP SIGNATURE----- >Version: PGP 8.0.2 > >iQA/AwUBPyDHZ6arNKXTPFCVEQLv4ACglmRgrDhl016UM3eFuoMJIeC8S4IAoOjZ >rE+ua7aSX9WYbdzoKTkd2ZKA >=88jJ >-----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jul 29 07:39:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19207 for ; Tue, 29 Jul 2003 07:39:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hSot-0008RT-MB for multi6-data@psg.com; Tue, 29 Jul 2003 11:39:07 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19hSor-0008Qr-12 for multi6@ops.ietf.org; Tue, 29 Jul 2003 11:39:05 +0000 From: Masataka Ohta Message-Id: <200307291131.UAA00888@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA00888; Tue, 29 Jul 2003 20:31:04 +0900 Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) In-Reply-To: from marcelo bagnulo at "Jul 29, 2003 11:15:02 am" To: marcelo bagnulo Date: Tue, 29 Jul 2003 20:31:04 +0859 () CC: Pekka Nikander , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Marcelo; > > So far, it is just a well known MITM attack no specific to multihoming. > > Again, have you heard about time shifting attacks? Have you ever serached the phrase "time shifting attacks" on the web? There is no such attack. Please don't try to invent new terminology for nothing. > This type of attack is not possible in regular IPv6 communications and > multi-homing mechanisms can enable them. Wrong. > The same goes for some flooding attacks. By inventing "time shifting attack", you ignore two facts, at least. One is that DoS can not be prevented. The other is that there is timeout on bindings. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jul 29 07:39:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19230 for ; Tue, 29 Jul 2003 07:39:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hSp6-0008Tn-PU for multi6-data@psg.com; Tue, 29 Jul 2003 11:39:20 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19hSp3-0008T5-1L for multi6@ops.ietf.org; Tue, 29 Jul 2003 11:39:17 +0000 From: Masataka Ohta Message-Id: <200307291124.UAA00852@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA00852; Tue, 29 Jul 2003 20:24:32 +0900 Subject: Re: Minutes / Notes In-Reply-To: <5A499F30-C1AF-11D7-958B-000393A638B2@kurtis.pp.se> from Kurt Erik Lindqvist at "Jul 29, 2003 12:28:10 pm" To: Kurt Erik Lindqvist Date: Tue, 29 Jul 2003 20:24:31 +0859 () CC: marcelo bagnulo , Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >> b) Introducing loc / id separation will require mapping, one way or > >> the > >> other. > > > > Wrong. The separation requires that a host know id and locators of > > its peer with reasonable security. > > That is a mapping state in it self. It is a state. You can call it a mapped state. But, there is no mapping service required. That no service required means no additional security required. > >> This introduces new bindings that needs to be secured. > > > > The separation requires that a host know id and locators of its > > peer with reasonable security. An initial packet of a connection > > containing all of them is just secure. > > That is as secure as the trust relationship of the creator of the > packet. Exactly. That is, the statement: > >> This introduces new bindings that needs to be secured. is wrong and the existing bindings has certain security which is just enough for weak security. HIP, having no trust relationship between the creators of the initial packets, for example, means no better security, even though HIP tries to, in vain, cryptographically maintain identify of the creators. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jul 29 08:09:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19846 for ; Tue, 29 Jul 2003 08:09:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hTHt-000BAo-AQ for multi6-data@psg.com; Tue, 29 Jul 2003 12:09:05 +0000 Received: from [192.71.80.74] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.20) id 19hTHr-000BAa-1y for multi6@ops.ietf.org; Tue, 29 Jul 2003 12:09:03 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6TC8vFJ006142; Tue, 29 Jul 2003 14:09:02 +0200 (CEST) Date: Tue, 29 Jul 2003 14:08:52 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: marcelo bagnulo , Iljitsch van Beijnum , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200307291105.UAA00541@necom830.hpcl.titech.ac.jp> Message-Id: <6B14027C-C1BD-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>> I guess Iljitsch was talking about stateless autoconfig RFC 2462 >>>>> >>>>> RFC2462 does not give any useful definition of autoconfiguration. >>>>> >>>>> For example, in DNSOP WG, people, including those of IPv6 ones, >>>>> are discussing autoconfiguration with DHCP. >>>> >>>> Yes. But in the meeting it was pointed out after your question that >>>> this was referring to the features described in 2462. >>> >>> And, then, it was pointed out that RFC 2462 is useless to define >>> autoconfiguration. >> >> Noone said that 2462 gives the definition of autoconfiguration. > > Wrong. > > My question is on definition of autoconfiguration of the > presentation by Iljitsch. > > Iljitsch could not provide any answer. From what I remember Iljitsch said he didn't know the RFC number. > As I further asked, Erik said that 2462 gives the definition of > the autoconfiguration of the presentation. I remember this as Erik saying that 2462 was what was referred to with "autoconfiguration". >> I think that anything that can improve the security of todays >> Internet, >> tomorrows Internet and yesterdays Internet will be looked upon >> favorably. > > An abstract nonsense. So you think that keeping security the way it is today is more desirable than improving it? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyZj1qarNKXTPFCVEQK6GgCZAVTqZs2BOgWJLwR2KL5iLlhDHzcAn1xE woFNcTs/Pw5pLOijeg0n/mx5 =Fl2/ -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jul 29 08:13:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19942 for ; Tue, 29 Jul 2003 08:13:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hTLh-000BT6-Jx for multi6-data@psg.com; Tue, 29 Jul 2003 12:13:01 +0000 Received: from [192.71.80.74] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.20) id 19hTLf-000BSq-4i for multi6@ops.ietf.org; Tue, 29 Jul 2003 12:12:59 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6TCBlFJ006145; Tue, 29 Jul 2003 14:11:47 +0200 (CEST) Date: Tue, 29 Jul 2003 14:11:42 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Iljitsch van Beijnum , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200307291115.UAA00688@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> AFAIK there is no published standard for DHVPv6 >>> >>> And there is no published standard for LIN6, though LIN6 does >>> exist in IPv6. >> >> There are a lot of things that exists and that is related to IP, TCP, >> UDP and the Internet that is not standard. >> >>> It should be noted that people working on IPv6 autoconfiguration >>> now assumes DHCPv6. >> >> From what I have been reading people seems to be assuming DHCPv6 and >> 2462. > > Are you now saying DHCPv6 defined? If you are saying it defined, > where, do you think, I can find your definition? Ok, poor wording in the mail you quoted and the one before that. With defined I meant published as standard. As Ralph points out in his mail this is however close though. > From what I have been reading some people seems to be assuming > DHCPv6 by ignoring 2462. Some other people seems to be simultaneously > assuming both DHCPv6 and 2462 ignoring the contradiction between them. This I agree with. > While I can continue the argument, others may not. As an expert on > autoconfiguration issues, my advice on the WG is that multi6 WG > should ignore autoconfiguration entirely unless useful definition > of it could be defined by someone else. > Agreed. All this started with the discussion on what was said in the minutes, and this is way off-topic. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyZkgKarNKXTPFCVEQL7cwCggmQSsGxL1+7lT5dausw5Ka3swtoAoMuH r1n0d5XV8P+S9kPeuEJSqVH+ =/9zy -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jul 29 08:16:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20005 for ; Tue, 29 Jul 2003 08:16:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hTOe-000Bi7-U8 for multi6-data@psg.com; Tue, 29 Jul 2003 12:16:04 +0000 Received: from [192.71.80.74] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.20) id 19hTOc-000Bhs-AP for multi6@ops.ietf.org; Tue, 29 Jul 2003 12:16:02 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6TCFsFJ006149; Tue, 29 Jul 2003 14:15:54 +0200 (CEST) Date: Tue, 29 Jul 2003 14:15:43 +0200 Subject: Re: Minutes / Notes Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: marcelo bagnulo , Iljitsch van Beijnum , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200307291124.UAA00852@necom830.hpcl.titech.ac.jp> Message-Id: <600B5D5C-C1BE-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> b) Introducing loc / id separation will require mapping, one way or >>>> the >>>> other. >>> >>> Wrong. The separation requires that a host know id and locators of >>> its peer with reasonable security. >> >> That is a mapping state in it self. > > It is a state. You can call it a mapped state. But, there is no > mapping service required. This depends on what you mean with mapping service. > That no service required means no additional security required. You suggested that the tokens be transfered OOB, that is a security and a state as well. Most likely a very costly one. >>>> This introduces new bindings that needs to be secured. > > is wrong and the existing bindings has certain security which > is just enough for weak security. The bindings will need some form of security. How you do this is part of the discussion. > HIP, having no trust relationship between the creators of the initial > packets, for example, means no better security, even though HIP > tries to, in vain, cryptographically maintain identify of the creators. I think this has been discussed by Pekka already. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyZld6arNKXTPFCVEQLpUQCg2w0CvWO5my6RRmXQ4skGlX6gJLIAoJBZ WQDqanZuYWEhiFD3xLyl5XJV =avUm -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jul 29 08:20:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20181 for ; Tue, 29 Jul 2003 08:20:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hTSD-000ByT-7Y for multi6-data@psg.com; Tue, 29 Jul 2003 12:19:45 +0000 Received: from [192.71.80.74] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.20) id 19hTSA-000BxH-Hl for multi6@ops.ietf.org; Tue, 29 Jul 2003 12:19:42 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6TCJUFJ006152; Tue, 29 Jul 2003 14:19:31 +0200 (CEST) Date: Tue, 29 Jul 2003 14:19:23 +0200 Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: marcelo bagnulo , Pekka Nikander , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200307291131.UAA00888@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> So far, it is just a well known MITM attack no specific to >>> multihoming. >> >> Again, have you heard about time shifting attacks? > > Have you ever serached the phrase "time shifting attacks" on the web? Google gives me 14 hits for that exact spelling. "time shifting" attacks gives me 948 hits. > There is no such attack. The links from Google seems to indicate otherwise. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyZmTqarNKXTPFCVEQJ/TwCbBi/Yc+emN0dOJtI6j2SqyNvfGTwAoMOs Li60QzP631Fhhjpo8JPyS/AP =ExKY -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jul 29 08:50:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21367 for ; Tue, 29 Jul 2003 08:50:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hTuk-000EPA-6d for multi6-data@psg.com; Tue, 29 Jul 2003 12:49:14 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19hTuh-000EOo-ML for multi6@ops.ietf.org; Tue, 29 Jul 2003 12:49:12 +0000 From: Masataka Ohta Message-Id: <200307291242.VAA00880@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA00880; Tue, 29 Jul 2003 21:42:07 +0900 Subject: Re: Minutes / Notes In-Reply-To: <6B14027C-C1BD-11D7-958B-000393A638B2@kurtis.pp.se> from Kurt Erik Lindqvist at "Jul 29, 2003 02:08:52 pm" To: Kurt Erik Lindqvist Date: Tue, 29 Jul 2003 21:42:05 +0859 () CC: marcelo bagnulo , Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >>>>> RFC2462 does not give any useful definition of autoconfiguration. > >> Noone said that 2462 gives the definition of autoconfiguration. > > As I further asked, Erik said that 2462 gives the definition of > > the autoconfiguration of the presentation. > > I remember this as Erik saying that 2462 was what was referred to with > "autoconfiguration". So? What is your point? Erik said that 2462 was what was referred to with "autoconfiguration" of the presentation. However, as I repeatedly said with evidences of confusions in other WGs: > >>>>> RFC2462 does not give any useful definition of autoconfiguration. Are you agreeing with me that RFC2462 is nothing? > > An abstract nonsense. > > So you think that keeping security the way it is today is more > desirable than improving it? It is not my statement but is a simple fact of life that the best thing we can do on security is keeping security the way it is today. Any attempt to do otherwise is to degrade it. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jul 29 08:50:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21428 for ; Tue, 29 Jul 2003 08:50:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hTv2-000EQH-22 for multi6-data@psg.com; Tue, 29 Jul 2003 12:49:32 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19hTuy-000EPu-Qd for multi6@ops.ietf.org; Tue, 29 Jul 2003 12:49:29 +0000 From: Masataka Ohta Message-Id: <200307291233.VAA00781@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA00781; Tue, 29 Jul 2003 21:33:40 +0900 Subject: Re: Minutes / Notes In-Reply-To: from Kurt Erik Lindqvist at "Jul 29, 2003 12:59:45 pm" To: Kurt Erik Lindqvist Date: Tue, 29 Jul 2003 21:33:39 +0859 () CC: marcelo bagnulo , Pekka Nikander , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > > It is a remark on people observed in other WG believing in > > autoconfigured security. As my remark continued, HIP, for > > example, does not assume so. > > No, but you are attributing a view on the intelligence of people > proposing a certain solution. This is what I am telling you to stop. The stupidity is of those people merely stating their vague desire not proposing any kind of solution to satisfy it. I understand that is not what you wrongly told me to stop. > >> About the roadmap/more desing teams thing: I'm afraid of a situation > >> where a good core idea doesn't take some limitations in consideration > >> so the resulting proposal is flawed. It looks like this is already the > >> case with e2e/lin6, > > > > is not a very professional remark, actually quite the opposite, > > because it is a unfounded and weak remark contributing nothing > > constructive. > > > > This does not attribute anything to anyone. It talks about a specific > proposal. It attributes something to someon who made the proposal. > Please refrain from comments on other members of the WG. You please refrain from comments on other members of the WG. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jul 29 08:59:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21621 for ; Tue, 29 Jul 2003 08:59:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hU4V-000FRU-Qw for multi6-data@psg.com; Tue, 29 Jul 2003 12:59:19 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19hU4S-000FR9-9k for multi6@ops.ietf.org; Tue, 29 Jul 2003 12:59:16 +0000 From: Masataka Ohta Message-Id: <200307291252.VAA01082@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA01082; Tue, 29 Jul 2003 21:52:09 +0900 Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) In-Reply-To: from Kurt Erik Lindqvist at "Jul 29, 2003 02:19:23 pm" To: Kurt Erik Lindqvist Date: Tue, 29 Jul 2003 21:52:08 +0859 () CC: marcelo bagnulo , Pekka Nikander , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > >>> So far, it is just a well known MITM attack no specific to > >>> multihoming. > >> > >> Again, have you heard about time shifting attacks? > > > > Have you ever serached the phrase "time shifting attacks" on the web? > > Google gives me 14 hits for that exact spelling. Haven't you checked them originated from Marcelo and his party? It is trivially easy to have 14 bits with google that it means nothing. Massataka Ohta From owner-multi6@ops.ietf.org Tue Jul 29 09:00:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21658 for ; Tue, 29 Jul 2003 09:00:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hU4k-000FSN-Nz for multi6-data@psg.com; Tue, 29 Jul 2003 12:59:34 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19hU4g-000FRo-Vk for multi6@ops.ietf.org; Tue, 29 Jul 2003 12:59:31 +0000 From: Masataka Ohta Message-Id: <200307291250.VAA00996@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA00996; Tue, 29 Jul 2003 21:50:17 +0900 Subject: Re: Minutes / Notes In-Reply-To: <600B5D5C-C1BE-11D7-958B-000393A638B2@kurtis.pp.se> from Kurt Erik Lindqvist at "Jul 29, 2003 02:15:43 pm" To: Kurt Erik Lindqvist Date: Tue, 29 Jul 2003 21:50:16 +0859 () CC: marcelo bagnulo , Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >>>> b) Introducing loc / id separation will require mapping, one way or > >>>> the > >>>> other. > >>> > >>> Wrong. The separation requires that a host know id and locators of > >>> its peer with reasonable security. > >> > >> That is a mapping state in it self. > > > > It is a state. You can call it a mapped state. But, there is no > > mapping service required. > > This depends on what you mean with mapping service. OK, we have no disagreement here, save minor terminology issues. > > That no service required means no additional security required. > > You suggested that the tokens be transfered OOB, No, not in general. However, it is requied for mobility though. It should be noted that, when IPv4 mobility was developed, security experts reviewed the protocol and modified it to reuire the security with the shared secret transfered OOB. > that is a security and > a state as well. Most likely a very costly one. So? Mobility costs, of course. > >>>> This introduces new bindings that needs to be secured. > > > > is wrong and the existing bindings has certain security which > > is just enough for weak security. > > The bindings will need some form of security. How you do this is part > of the discussion. I have been saying that that they are contained in a single packet means binding with just enough security. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jul 29 09:09:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21877 for ; Tue, 29 Jul 2003 09:09:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hUDy-000GXp-EJ for multi6-data@psg.com; Tue, 29 Jul 2003 13:09:06 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19hUDv-000GXX-VP for multi6@ops.ietf.org; Tue, 29 Jul 2003 13:09:04 +0000 From: Masataka Ohta Message-Id: <200307291254.VAA01178@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA01178; Tue, 29 Jul 2003 21:54:38 +0900 Subject: Re: Minutes / Notes In-Reply-To: from Kurt Erik Lindqvist at "Jul 29, 2003 02:11:42 pm" To: Kurt Erik Lindqvist Date: Tue, 29 Jul 2003 21:54:37 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > > While I can continue the argument, others may not. As an expert on > > autoconfiguration issues, my advice on the WG is that multi6 WG > > should ignore autoconfiguration entirely unless useful definition > > of it could be defined by someone else. > > > > Agreed. All this started with the discussion on what was said in the > minutes, and this is way off-topic. No. My point started with the discussion on what was said in the slide of Iljitcsh. I'm glad that you admit a point on "Cons" of "Small" is wrong. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jul 29 09:50:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22694 for ; Tue, 29 Jul 2003 09:50:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hUqV-000KAe-98 for multi6-data@psg.com; Tue, 29 Jul 2003 13:48:55 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.20) id 19hUqS-000KAR-BW for multi6@ops.ietf.org; Tue, 29 Jul 2003 13:48:52 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 97F0F43159; Tue, 29 Jul 2003 15:48:51 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.224]) by smtp01.uc3m.es (Postfix) with SMTP id 85E3599E73; Tue, 29 Jul 2003 15:48:51 +0200 (CEST) From: "marcelo bagnulo" To: "Masataka Ohta" Cc: Subject: RE: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) Date: Tue, 29 Jul 2003 15:47:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200307291131.UAA00888@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Spam-Status: No, hits=-18.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is my last mail on this thread. please read draft-nikander-mobileip-v6-ro-sec-01.txt and then we can continue this exchange (probably when you read the draft there will be no need to continue this, though) i cannot say that i have invented those attacks, not even the terminology, these are described in the draft and i am not one the authors. I guess that the google hits that Kurt discovered are not my responsability neither. marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Masataka Ohta > Enviado el: martes, 29 de julio de 2003 13:32 > Para: marcelo bagnulo > CC: Pekka Nikander; multi6@ops.ietf.org > Asunto: Re: Reasonable to use crypto in all communications? (Re: Fwd: > Minutes/Notes) > > > Marcelo; > > > > So far, it is just a well known MITM attack no specific to > multihoming. > > > > Again, have you heard about time shifting attacks? > > Have you ever serached the phrase "time shifting attacks" on the web? > > There is no such attack. > > Please don't try to invent new terminology for nothing. > > > This type of attack is not possible in regular IPv6 communications and > > multi-homing mechanisms can enable them. > > Wrong. > > > The same goes for some flooding attacks. > > By inventing "time shifting attack", you ignore two facts, at least. > > One is that DoS can not be prevented. > > The other is that there is timeout on bindings. > > Masataka Ohta > From owner-multi6@ops.ietf.org Tue Jul 29 18:06:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12001 for ; Tue, 29 Jul 2003 18:06:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hcaI-0006TP-Mk for multi6-data@psg.com; Tue, 29 Jul 2003 22:04:42 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.20) id 19hcaE-0006TC-Ov for multi6@ops.ietf.org; Tue, 29 Jul 2003 22:04:38 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 2FE893448A; Tue, 29 Jul 2003 15:03:13 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6TM4YYB026260; Tue, 29 Jul 2003 15:04:35 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) Date: Tue, 29 Jul 2003 15:04:34 -0700 Message-ID: Thread-Topic: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) Thread-Index: AcNVwkTkMcc7mHvOT5OSjKrcqNqC9wAWwhhg From: "Tony Li" To: "Kurt Erik Lindqvist" Cc: "Pekka Nikander" , "marcelo bagnulo" , X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Thanks for pointing to my glaring lack of detail. Yes, Steve will be working with design team 1. Tony | -----Original Message----- | From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se]=20 | Sent: Tuesday, July 29, 2003 12:12 PM | To: Tony Li | Cc: Pekka Nikander; marcelo bagnulo; multi6@ops.ietf.org | Subject: Re: Reasonable to use crypto in all=20 | communications? (Re: Fwd: Minutes/Notes) | =20 | =20 | -----BEGIN PGP SIGNED MESSAGE----- | Hash: SHA1 | =20 | =20 | =20 | Tony, | =20 | =20 | > | I am starting to think that we would need a proper security | > | analysis on multi-address multi-homing. I might be willing | > | to spend some cycles on writing a draft on that, but only | > | later in the fall (starting from mid September or so). | > | > | > Actually, we've already been able to draft Steve Bellovin to help | > us out here. Thanks for volunteering tho. | > | =20 | =20 | Are you saying that you will also present a draft on this,=20 | or are you=20 | saying that you have enlisted Steve for working with=20 | design-team-1 (for=20 | lack of better separation)? | =20 | I think that a draft outlining security threats for=20 | multi-addressing=20 | would also be good, perhaps working with design-team-2? | =20 | - - kurtis - | =20 | -----BEGIN PGP SIGNATURE----- | Version: PGP 8.0.2 | =20 | iQA/AwUBPyZWhKarNKXTPFCVEQKA/QCfXwfh4IeNBlzwopk2waAeiaeWqAAAoK0k | bTOAvF2GAnESRwdCEIDPNXP+ | =3DvSUl | -----END PGP SIGNATURE----- | =20 | =20 From owner-multi6@ops.ietf.org Wed Jul 30 01:51:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23863 for ; Wed, 30 Jul 2003 01:51:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hjpt-000Cqy-3f for multi6-data@psg.com; Wed, 30 Jul 2003 05:49:17 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19hjpq-000Cqm-Jo for multi6@ops.ietf.org; Wed, 30 Jul 2003 05:49:14 +0000 From: Masataka Ohta Message-Id: <200307300537.OAA03276@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA03276; Wed, 30 Jul 2003 14:37:19 +0900 Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) In-Reply-To: from marcelo bagnulo at "Jul 29, 2003 03:47:11 pm" To: marcelo bagnulo Date: Wed, 30 Jul 2003 14:37:18 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-8.9 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Marcelo; > This is my last mail on this thread. That should be wise for you. Never try to use a strange terminlogy on such a common attack mode merely to use a compromised entity for latter attacks. Masataka Ohta From owner-multi6@ops.ietf.org Wed Jul 30 07:57:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27522 for ; Wed, 30 Jul 2003 07:57:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hpXY-0009nb-GT for multi6-data@psg.com; Wed, 30 Jul 2003 11:54:44 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.20) id 19hpXS-0009nL-FA for multi6@ops.ietf.org; Wed, 30 Jul 2003 11:54:38 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6UBsWIJ019228; Wed, 30 Jul 2003 05:54:33 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6UBsVQ18863; Wed, 30 Jul 2003 13:54:32 +0200 (MEST) Date: Wed, 30 Jul 2003 13:52:19 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) To: Pekka Nikander Cc: marcelo bagnulo , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <3F20CC2A.4030809@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > What comes to crypto binding, I am only aware of two possibilities: > Using asymmetric keys (or something similar) as primary identifiers, > or using CGA (or something similar). All the other solutions that > I know about require some kind of infrastructure, some kind of > an enrollment procedure, or both. I guess I don't really understand your categorization. If one wants to have the IP packets be bound to some existing identity (like something one would find in a PKI: subject-name erik.nordmar@sun.com with some particular trust anchor) then one would always need something at least approximating a PKI. If one is only concerned about the IP packets be bound to some ephemeral (and meaningless to higher level protocols?) identity than one can either have the primary identifier be variable length (e.g. a public key; a (self-signed) certificate), or fixed length (e.g. a hash of a public key or a hash of a (self-signed) certificate). That still allows the identifiers to be long-term stable, as well as new identifiers being fabricated on the fly to get "anonymity". Finally, if one only is concerned about being able to verify that some IP packet is sent by the same entity that sent some previous IP packet, then PBK type approaches would seem to fit (e.g. do an anonymous DH exchange up front and use the resulting key to protect changes to the id/loc mapping.) Erik From owner-multi6@ops.ietf.org Wed Jul 30 08:00:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27603 for ; Wed, 30 Jul 2003 08:00:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hpcu-000AIy-Q4 for multi6-data@psg.com; Wed, 30 Jul 2003 12:00:16 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.20) id 19hpcr-000AHu-1c for multi6@ops.ietf.org; Wed, 30 Jul 2003 12:00:13 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6UC08IJ021899; Wed, 30 Jul 2003 06:00:09 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6UC08Q19138; Wed, 30 Jul 2003 14:00:08 +0200 (MEST) Date: Wed, 30 Jul 2003 13:57:55 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: distributed hash tables To: Iljitsch van Beijnum Cc: Christian Huitema , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <1232FC57-BE80-11D7-B006-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > If you can distribute your information over a set of reliable and > trustworthy nodes, this could work very well. However, we can't assume > any one node to be reliable, so we need to build in a good deal of > redundancy and dynamic replication. This also means that a resolver may > need to contact several nodes in sequence to find the required > information. But it gets worse: a node that is supposed to hold a > certain piece of information could, rather than hand over the requested > information, claim that the information doesn't exist. The only way > that I can see to get around this is distribute copies of the same > piece of information over so many nodes that it becomes infeasible to > corrupt them all. Which probably means there isn't a workable tradeoff > between security/reliability and performance. > > So essentially this has all the downsides of DNS and then some, with > the only advantage that you now get to search in flat spaces too. I guess we don't agree on the parameters of the problem we are trying to solve yet. One possible set of parameters is that the identifier space is hierarchically structured with "sufficient" hierarchy. In such a case a hierarchical lookup system like the DNS might be appropriate. Another possible set of parameters is that the identifier space is flat (for example, an ID is based on a hash of a public key) or with limited hiearchy (e.g., N bits of flat site ID followed by 128-N bits of flat "ID within site"). In that case a hierarchical lookup system like the DNS doesn't seem like a good fit. Figuring out how to use a DHT in the latter case has some issues that folks need to look at. In addition to the ones you pointed out, one would also need to be able to do DHT resolution for nodes belonging to the same site when the site is cut off from the rest of the internet. Erik From owner-multi6@ops.ietf.org Wed Jul 30 14:03:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11005 for ; Wed, 30 Jul 2003 14:03:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hvFe-000BFM-GH for multi6-data@psg.com; Wed, 30 Jul 2003 18:00:38 +0000 Received: from [209.226.175.187] (helo=tomts24-srv.bellnexxia.net) by psg.com with esmtp (Exim 4.20) id 19hvFa-000BF6-Ab for multi6@ops.ietf.org; Wed, 30 Jul 2003 18:00:34 +0000 Received: from yahoo.com ([65.93.188.142]) by tomts24-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030730180032.CGJS20400.tomts24-srv.bellnexxia.net@yahoo.com>; Wed, 30 Jul 2003 14:00:32 -0400 Date: Wed, 30 Jul 2003 14:00:34 -0400 Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Masataka Ohta From: S Woodside In-Reply-To: <200307291131.UAA00888@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-13.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,FORGED_YAHOO_RCVD,IN_REP_TO, RCVD_FAKE_HELO_DOTCOM,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Please attack the ideas that people express and not the people. simon On Tuesday, July 29, 2003, at 07:32 AM, Masataka Ohta wrote: > Please don't try to invent new terminology for nothing. > -- www.simonwoodside.com -- 99% Devil, 1% Angel From owner-multi6@ops.ietf.org Wed Jul 30 18:00:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20013 for ; Wed, 30 Jul 2003 18:00:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hyyj-0004V2-N5 for multi6-data@psg.com; Wed, 30 Jul 2003 21:59:25 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19hyyd-0004Un-DR for multi6@ops.ietf.org; Wed, 30 Jul 2003 21:59:19 +0000 From: Masataka Ohta Message-Id: <200307302145.GAA10894@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA10894; Thu, 31 Jul 2003 06:45:04 +0900 Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) In-Reply-To: from S Woodside at "Jul 30, 2003 02:00:34 pm" To: S Woodside Date: Thu, 31 Jul 2003 06:45:03 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-11.3 required=5.0 tests=BAYES_10,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk simon; > Please attack the ideas that people express and not the people. There is no idea to attack expressed. There are people insisting on their terminology on nothing. Masataka Ohta > simon > > On Tuesday, July 29, 2003, at 07:32 AM, Masataka Ohta wrote: > > > Please don't try to invent new terminology for nothing. > > > > -- > www.simonwoodside.com -- 99% Devil, 1% Angel > > > From owner-multi6@ops.ietf.org Wed Jul 30 22:54:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27406 for ; Wed, 30 Jul 2003 22:54:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19i3Y7-000Ph7-Nq for multi6-data@psg.com; Thu, 31 Jul 2003 02:52:15 +0000 Received: from [209.226.175.187] (helo=tomts24-srv.bellnexxia.net) by psg.com with esmtp (Exim 4.20) id 19i3Y5-000PgT-8S for multi6@ops.ietf.org; Thu, 31 Jul 2003 02:52:13 +0000 Received: from yahoo.com ([65.93.188.168]) by tomts24-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030731025211.SWSK20400.tomts24-srv.bellnexxia.net@yahoo.com>; Wed, 30 Jul 2003 22:52:11 -0400 Date: Wed, 30 Jul 2003 22:52:10 -0400 Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Masataka Ohta From: S Woodside In-Reply-To: <200307302145.GAA10894@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-22.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,FORGED_YAHOO_RCVD,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_FAKE_HELO_DOTCOM,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, July 30, 2003, at 05:46 PM, Masataka Ohta wrote: >> Please attack the ideas that people express and not the people. > There is no idea to attack expressed. Then attack the non-existence of the idea and not the people ... simon -- www.simonwoodside.com -- 99% Devil, 1% Angel From owner-multi6@ops.ietf.org Thu Jul 31 00:00:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28421 for ; Thu, 31 Jul 2003 00:00:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19i4b4-0004Pz-Ee for multi6-data@psg.com; Thu, 31 Jul 2003 03:59:22 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19i4b2-0004Pm-3W for multi6@ops.ietf.org; Thu, 31 Jul 2003 03:59:20 +0000 From: Masataka Ohta Message-Id: <200307310349.MAA08714@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA08714; Thu, 31 Jul 2003 12:49:08 +0900 Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) In-Reply-To: from S Woodside at "Jul 30, 2003 10:52:10 pm" To: S Woodside Date: Thu, 31 Jul 2003 12:49:05 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk simon; : There is no idea to attack expressed. : There are people insisting on their terminology on nothing. > >> Please attack the ideas that people express and not the people. > > There is no idea to attack expressed. > > Then attack the non-existence of the idea and not the people ... That is an attack only on the first problem but, yes, I did so, but Marcelo insisted. Masataka Ohta