From owner-multi6@ops.ietf.org Tue Jun 5 05:37:38 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13754 for ; Tue, 5 Jun 2001 05:37:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157DDv-0005cZ-00 for multi6-data@psg.com; Tue, 05 Jun 2001 02:34:03 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 157DDu-0005cN-00 for multi6@ops.ietf.org; Tue, 05 Jun 2001 02:34:02 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f559Y0H63399 for ; Tue, 5 Jun 2001 11:34:00 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 5 Jun 2001 11:33:00 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: multi6@ops.ietf.org Subject: Regionally aggregatable address space for multihoming Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi. I guess I'll jump right in. After reading "IAB/IESG Recommendations on IPv6 Address Allocations to Sites" it occurred to me that a way to keep the number of routes in the routing tables down could be to use regionally aggregatable address space for multihoming. The idea is that routers on one end of the globe have little need to know very specific routes to multihomed networks in some another part of the world. For instance, a router on the US west coast doesn't need to know how a network in Europe is connected. It should just send the packet to the east. At some point, the packet would end up in the destination region, or as close to the destination region as the originating network extends, and only there the originating network would have to know where to send the packet next. Individual networks could implement filters in strategic places to keep the specific routes for multihomed networks inside the proper region. There is no requirement that networks use the same regional subdivision: a European network may use regions that map to two countries, while another network that has only a few points of presence in Europe may see the entire continent as a region. Some networks may prefer to keep carrying all routes everywhere. All networks announce their customer's routes everywhere, but peers simply filter out these announcements on exchange points that do not fall within their idea of the region. So our European network would normally only accept routes to Dutch addresses in Amsterdam and Brussels (for backup) but the other network only connects to the exchanges in London and Paris so it would pick up the announcements for the Dutch multihomed address range there. A further reduction of the routing tables could be possible by installing exchange routers for regions at internet exchanges. The exchange router would announce an aggregate for the region and all networks may send traffic to that router. The exchange router holds all the more specific routes for the aggregate and forwards the packets to one of the providers for the destination network. A problem with this is that all networks that have multihomed customers in a region must connect to all the exchanges where the aggregate is announced. All other default free networks have to connect to at least two of the exchanges for that region. Exchange routers should be present outside as well as within the region they service, for reasons of redundancy and because not all networks are present in all regions. The granularity of the address assignments has to be fairly fine, so that it doesn't conflict with the hierarchical structure of any existing network. A granularity of 1 to 10 million people to a region seems reasonable. (This would mean large cities or small countries/states/provinces.) With potentially 1% of the population being multihomed that would make for about 100k routes per region, so today's routers would be able to handle several of those regions. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Jun 5 08:26:04 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17376 for ; Tue, 5 Jun 2001 08:26:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157Ftf-0009F9-00 for multi6-data@psg.com; Tue, 05 Jun 2001 05:25:19 -0700 Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by psg.com with esmtp (Exim 3.16 #1) id 157Ftf-0009En-00 for multi6@ops.ietf.org; Tue, 05 Jun 2001 05:25:19 -0700 Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id FAA29122; Tue, 5 Jun 2001 05:24:40 -0700 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id FAA20812; Tue, 5 Jun 2001 05:24:37 -0700 Message-ID: <3B1CCFA8.300E0BB7@hursley.ibm.com> Date: Tue, 05 Jun 2001 07:25:12 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Iljitsch van Beijnum CC: multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit How would this work for intercontinental private networks, whose multiple connection points are in several different continents? Brian Iljitsch van Beijnum wrote: > > Hi. > > I guess I'll jump right in. > > After reading "IAB/IESG Recommendations on IPv6 Address Allocations to > Sites" it occurred to me that a way to keep the number of routes in the > routing tables down could be to use regionally aggregatable address space for > multihoming. > > The idea is that routers on one end of the globe have little need to know > very specific routes to multihomed networks in some another part of the > world. For instance, a router on the US west coast doesn't need to know how a > network in Europe is connected. It should just send the packet to the > east. At some point, the packet would end up in the destination region, or as > close to the destination region as the originating network extends, and only > there the originating network would have to know where to send the packet > next. > > Individual networks could implement filters in strategic places to keep the > specific routes for multihomed networks inside the proper region. There is no > requirement that networks use the same regional subdivision: a European > network may use regions that map to two countries, while another network that > has only a few points of presence in Europe may see the entire continent as a > region. Some networks may prefer to keep carrying all routes everywhere. > > All networks announce their customer's routes everywhere, but peers simply > filter out these announcements on exchange points that do not fall within > their idea of the region. So our European network would normally only accept > routes to Dutch addresses in Amsterdam and Brussels (for backup) but the > other network only connects to the exchanges in London and Paris so it would > pick up the announcements for the Dutch multihomed address range there. > > A further reduction of the routing tables could be possible by installing > exchange routers for regions at internet exchanges. The exchange router would > announce an aggregate for the region and all networks may send traffic to > that router. The exchange router holds all the more specific routes for the > aggregate and forwards the packets to one of the providers for the > destination network. > > A problem with this is that all networks that have multihomed customers in a > region must connect to all the exchanges where the aggregate is announced. > All other default free networks have to connect to at least two of the > exchanges for that region. Exchange routers should be present outside as well > as within the region they service, for reasons of redundancy and because not > all networks are present in all regions. > > The granularity of the address assignments has to be fairly fine, so that it > doesn't conflict with the hierarchical structure of any existing network. A > granularity of 1 to 10 million people to a region seems reasonable. (This > would mean large cities or small countries/states/provinces.) With > potentially 1% of the population being multihomed that would make for about > 100k routes per region, so today's routers would be able to handle several of > those regions. > > Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Jun 5 08:45:40 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18153 for ; Tue, 5 Jun 2001 08:45:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157GD5-0009Pg-00 for multi6-data@psg.com; Tue, 05 Jun 2001 05:45:23 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 157GD4-0009Pa-00 for multi6@ops.ietf.org; Tue, 05 Jun 2001 05:45:22 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f55CjJH63615; Tue, 5 Jun 2001 14:45:19 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 5 Jun 2001 14:44:17 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Brian E Carpenter cc: multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming In-Reply-To: <3B1CCFA8.300E0BB7@hursley.ibm.com> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 5 Jun 2001, Brian E Carpenter wrote: > How would this work for intercontinental private networks, > whose multiple connection points are in several different > continents? There are two ways this could work. Either the network basically functions as its own ISP, and it tries to attract traffic as close to the origin as possible, or it tries to keep the long distance lines free for private traffic and has ISPs transport the traffic to as close to the destination as possible. In the first case, they would use a globally visible PI address range and announce a single prefix everywhere in the world. In the second case, they would get a number of smaller regionally aggregatable ranges and use them in the appropriate regions. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Jun 5 09:29:14 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19920 for ; Tue, 5 Jun 2001 09:29:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157Gt6-0009f4-00 for multi6-data@psg.com; Tue, 05 Jun 2001 06:28:48 -0700 Received: from www.bit-net.com ([208.146.132.4] helo=mail.users.bit-net.com) by psg.com with smtp (Exim 3.16 #1) id 157Gt3-0009ew-00 for multi6@ops.ietf.org; Tue, 05 Jun 2001 06:28:45 -0700 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA04220; Tue, 5 Jun 2001 09:28:30 -0400 Date: Tue, 5 Jun 2001 09:28:30 -0400 (EDT) From: Jim Bound To: Brian E Carpenter Cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming In-Reply-To: <3B1CCFA8.300E0BB7@hursley.ibm.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk also for inter-planetary networks too. seriously I have people asking. /jim On Tue, 5 Jun 2001, Brian E Carpenter wrote: > How would this work for intercontinental private networks, > whose multiple connection points are in several different > continents? > > Brian > > Iljitsch van Beijnum wrote: > > > > Hi. > > > > I guess I'll jump right in. > > > > After reading "IAB/IESG Recommendations on IPv6 Address Allocations to > > Sites" it occurred to me that a way to keep the number of routes in the > > routing tables down could be to use regionally aggregatable address space for > > multihoming. > > > > The idea is that routers on one end of the globe have little need to know > > very specific routes to multihomed networks in some another part of the > > world. For instance, a router on the US west coast doesn't need to know how a > > network in Europe is connected. It should just send the packet to the > > east. At some point, the packet would end up in the destination region, or as > > close to the destination region as the originating network extends, and only > > there the originating network would have to know where to send the packet > > next. > > > > Individual networks could implement filters in strategic places to keep the > > specific routes for multihomed networks inside the proper region. There is no > > requirement that networks use the same regional subdivision: a European > > network may use regions that map to two countries, while another network that > > has only a few points of presence in Europe may see the entire continent as a > > region. Some networks may prefer to keep carrying all routes everywhere. > > > > All networks announce their customer's routes everywhere, but peers simply > > filter out these announcements on exchange points that do not fall within > > their idea of the region. So our European network would normally only accept > > routes to Dutch addresses in Amsterdam and Brussels (for backup) but the > > other network only connects to the exchanges in London and Paris so it would > > pick up the announcements for the Dutch multihomed address range there. > > > > A further reduction of the routing tables could be possible by installing > > exchange routers for regions at internet exchanges. The exchange router would > > announce an aggregate for the region and all networks may send traffic to > > that router. The exchange router holds all the more specific routes for the > > aggregate and forwards the packets to one of the providers for the > > destination network. > > > > A problem with this is that all networks that have multihomed customers in a > > region must connect to all the exchanges where the aggregate is announced. > > All other default free networks have to connect to at least two of the > > exchanges for that region. Exchange routers should be present outside as well > > as within the region they service, for reasons of redundancy and because not > > all networks are present in all regions. > > > > The granularity of the address assignments has to be fairly fine, so that it > > doesn't conflict with the hierarchical structure of any existing network. A > > granularity of 1 to 10 million people to a region seems reasonable. (This > > would mean large cities or small countries/states/provinces.) With > > potentially 1% of the population being multihomed that would make for about > > 100k routes per region, so today's routers would be able to handle several of > > those regions. > > > > Iljitsch van Beijnum > From owner-multi6@ops.ietf.org Tue Jun 5 09:53:39 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20854 for ; Tue, 5 Jun 2001 09:53:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157HG0-0009pG-00 for multi6-data@psg.com; Tue, 05 Jun 2001 06:52:28 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.16 #1) id 157HFz-0009p3-00 for multi6@ops.ietf.org; Tue, 05 Jun 2001 06:52:27 -0700 Received: from office.ripe.net (office.ripe.net [193.0.1.97]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id PAA12737; Tue, 5 Jun 2001 15:51:25 +0200 (CEST) Received: (from leo@localhost) by office.ripe.net (8.8.8/8.8.5) id PAA20520; Tue, 5 Jun 2001 15:51:24 +0200 (CEST) Date: Tue, 5 Jun 2001 15:51:24 +0200 From: leo vegoda To: Jim Bound Cc: Brian E Carpenter , Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming Message-ID: <20010605155124.D5726@ripe.net> References: <3B1CCFA8.300E0BB7@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Jim Bound on Tue, Jun 05, 2001 at 09:28:30AM -0400 X-Organization: RIPE Network Coordination Centre Organization: RIPE Network Coordination Centre X-phone: +31 20 535 4444 X-fax: +31 20 535 4445 X-URL: http://www.ripe.net X-I-look-like-this: http://www.bind.org/leo/ Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, Jun 05, 2001 at 09:28:30AM -0400, Jim Bound (seamus@bit-net.com) wrote: Re: Re: Regionally aggregatable address space for multihoming > also for inter-planetary networks too. seriously I have people asking. Interplanetary Internet (IPN): Architectural Definition http://www.ietf.org/internet-drafts/draft-irtf-ipnrg-arch-00.txt This ID suggests a separte Internet for each planet (or space-ship, or whatever) with a 'Bundle Layer' for the connections between them. Certainly an eye-opening read but probably slightly off-topic. Regards, -- leo vegoda "One size never fits all" RFC1925 - The Twelve Networking Truths From owner-multi6@ops.ietf.org Tue Jun 5 10:13:50 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21682 for ; Tue, 5 Jun 2001 10:13:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157HaZ-000A09-00 for multi6-data@psg.com; Tue, 05 Jun 2001 07:13:43 -0700 Received: from roxanne.roxanne.org ([206.113.40.2] helo=roxanne.org ident=eric) by psg.com with esmtp (Exim 3.16 #1) id 157HaY-000A00-00 for multi6@ops.ietf.org; Tue, 05 Jun 2001 07:13:42 -0700 Received: (from eric@localhost) by roxanne.org (8.8.4/8.8.4) id KAA19586 for multi6@ops.ietf.org; Tue, 5 Jun 2001 10:14:39 -0400 Date: Tue, 5 Jun 2001 10:14:39 -0400 From: Eric Gauthier To: multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming Message-ID: <20010605101439.B19476@roxanne.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, Jun 05, 2001 at 09:28:30AM -0400, Jim Bound wrote: > also for inter-planetary networks too. seriously I have people asking. For those who think he's kidding, check out this article from CNN.com back in February of this year... http://www.cnn.com/2001/TECH/internet/02/27/mars.network.office.idg/index.html Or the NASA agency working on it: http://marsnet.jpl.nasa.gov/ Eric :) From owner-multi6@ops.ietf.org Thu Jun 7 16:58:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14479 for ; Thu, 7 Jun 2001 16:58:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1586of-0008q7-00 for multi6-data@psg.com; Thu, 07 Jun 2001 13:55:41 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.16 #1) id 1586oe-0008q1-00 for multi6@ops.ietf.org; Thu, 07 Jun 2001 13:55:40 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 07 Jun 2001 13:55:24 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 4712B9E8DC7D459EBC215A734B0BA486 for plus 1 more; Thu, 07 Jun 2001 13:55:24 -0700 Reply-To: From: "Tony Hain" To: "Iljitsch van Beijnum" , Subject: RE: Regionally aggregatable address space for multihoming Date: Thu, 7 Jun 2001 13:55:23 -0700 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal X-SLUIDL: 3C2B93D7-6E134C8B-A2D6A316-49469F73 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Here is the text of a very drafty-draft I have been working on for a couple of weeks to address this specific issue. If things are not aligning right, try putting the font in Courier 12. Comments please. Tony Multi-6 Internet Draft T. Hain Document: draft-hain-ipv6-geo-addr-00.txt Cisco Expires: December 2001 June 2001 An IPv6 Provider Independent (Geographic) Global Unicast Address Format Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [i]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines an IPv6 Provider Independent global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [IPV6] and the "IPv6 Addressing Architecture" [ARCH]. It is designed to facilitate scalable Internet routing when sites attach to multiple service providers, by using a geographic reference to the site. A natural byproduct of this address allocation mechanism is that all addresses are portable allowing sites to change providers at will without requiring their network to renumber. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [ii]. Introduction This document defines an address format for the IPv6 provider independent global unicast address assignment based on geographic location. This address format is expected to complement the Aggregatable [RFC 2374] format by addressing some of the scaling concerns related to site multi-homing. Recent observations show that sites are frequently connecting to multiple service providers, and this breaks the base aggregation assumption in rfc 2374. The geographic nature of this provider independent address format is designed to provide sites with addresses which aggregate well in direct proportion to the distance from the site. It also allows a site to change providers without impacting the nodes or connections within a site. The mechanism breaks down the geographic location of the site into prefix lengths that map well into existing routing protocols. This will allow efficient routing aggregation for single sites that connect directly to multiple providers and for sites that connect to metropolitan scale exchanges. Sites will have the choice to connect to either type of aggregation entity. The details about specific site topology will be limited to the service providers that are making the direct connections. This format will also work well for organizations with multiple sites distributed geographically, when used concurrently with [draft-draves-addr-selection]. As each end system will select the source address that has the longest match with the destination, connections will naturally find the transition point between the organizations private network and the public Internet that is closest to the publicly connected site. The basic mechanism is an Earth surface location defined by WGS-84 latitude/longitude that represents the center of a nominal square approximately 10 meters on a side. An interleave is used to create a 44-bit address, if necessary dropping the low order nibbles allows for local management and increases flexibility of assignments to sites by expanding the grid scope. While this address format is designed to support exchange-based aggregation in a metro context, it is not dependent on exchanges for it's overall route aggregation properties. It will provide efficient route aggregation in a global context when providers in a metro region interconnect by whatever means, and only announce the shorter prefix outside. Any provider announcing a short prefix SHOULD be able to deliver packets to anywhere in the region, either directly or through other arrangements. In the case where a service provider does not interconnect with others in its region it MUST advertise the longer prefixes associated with its customers. IPv6 defines the case that nodes will have multiple addresses so having a set of provider independent ones as well as potentially several sets of provider dependent ones should not present any particular concerns to the end nodes. The primary technical issue will be limitations in the size of a DNS response packet. There may be concerns raised about timing out connection attempts, but [addr-selection] selection rules should consistently provide the optimal pairing of addresses. Addresses defined with this format prefix are not portable by definition. Entities that expect identifiers to be portable across physical location moves MUST use alternatives such as provider-based addresses [rfc 2374] or DNS names. Multi-site organizations SHOULD be using all the available prefixes; so if any specific facility moved, deprecating one should be a non-event for all but very long lifetime connections. Another issue is the business model being flipped from the current destination's ISP choice determines sources routing; to one of source's ISP choice determines at least its first hop. The other consideration is this may cause the traffic flow between ISPs to flip from dump-early to dump-late (in smallest peering scope of destination). The number of packets carried should remain the same, but the transit agreements may be the opposite direction from provider-based allocations. Question about how does an ISP find out what scope they can aggregate. If everyone just starts announcing site specific /48's and use the upstream pressure / feedback to correct the situation there is no need for a specific registration. Clearly all of the significant players in a region need to communicate well to contain the specifics, but the consequence of not doing that is simply a larger table at the next larger boundary. Providers at the larger scopes are motivated to encourage providers in the smaller scopes to interconnect locally and avoid announcing the specifics any wider than necessary. Overview of the IPv6 Address IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces. There are three types of addresses: Unicast, Anycast, and Multicast. This document defines a specific type of Unicast address. In this document, fields in addresses are given specific names, for example "subnet". When this name is used with the term "ID" (for "identifier") after the name (e.g., "subnet ID"), it refers to the contents of the named field. When it is used with the term "prefix" (e.g. "subnet prefix") it refers to all of the addressing bits to the left of and including this field. IPv6 unicast addresses are designed assuming that the Internet routing system makes forwarding decisions based on a "longest prefix match" algorithm on arbitrary bit boundaries and does not have any knowledge of the internal structure of IPv6 addresses. The structure in IPv6 addresses is for assignment and allocation. The only exception to this is the distinction made between unicast and multicast addresses. The specific type of an IPv6 address is indicated by the leading bits in the address. The variable-length field comprising these leading bits is called the Format Prefix (FP). This document defines an address format for the 0001 (binary) Format Prefix for Geographic Global Unicast addresses. The same address format could be used for other Format Prefixes, as long as these Format Prefixes also identify IPv6 unicast addresses. Only the "0001" Format Prefix is defined here. IPv6 Geographic Global Unicast Address Format Provider Independent addresses are organized into a nibble-based hierarchy using a 2-bit interleave of the WGS-84 based latitude and longitude of a site. While the available 44-bit field allows for resolution of a grid approximately 10 meters on a side, addressing privacy concerns may require the allocation to be at 40-bits with site assignments in that 40 meter grid to be managed by the smallest local jurisdiction. Accommodating dense population areas may require that the grid size be increased to 150 meters or more to allow a sufficient number of bits in the locally assigned field identifying the specific site. This will allow more flexible assignments for multi-story buildings and business centers with multiple independent sites per geographic grid. Actual assignments within a geographic grid will be a local jurisdictional issue (matching scope jurisdiction; building owner, community board, local government, etc.), and independent of any service provider. The only rules are that the allocation point MUST be measured at the center of, a grid and any overlap must be coordinated. If a grid needs to be expanded to accommodate density, it MUST avoid or otherwise coordinate use of any existing values that fall within its new boundaries. In the case where the local jurisdiction acts as a local service provider to its tenants, it MAY choose to allocate prefix lengths longer than /48 as appropriate for the number and needs of its customers. In any case the allocation MUST NOT exceed 64 bits in length. In a few places there may exist regions with extreme densities (greater than 1M independent sites per square 25 km on a side) where it is not reasonable to expand any given grid to a sufficiently large area to provide enough addresses for local administration. Generally these are expected to be adjacent to sizable regions of water where it is highly unlikely there will ever be permanent Internet service provided. The local jurisdiction for areas of extreme density may choose to map a nearby unusable grid onto an area requiring more addresses. When this is done the jurisdiction MUST coordinate with neighbors to avoid duplication. This address allocation mechanism SHOULD NOT be used on a dial access network pop, as scaling routes to sites attached this way are best addressed through provider based allocations consistent with Aggregatable [RFC 2374]. Service provision from points of attachment for wireless nodes MAY choose to allocate prefixes longer than 48 bits (from the site prefix for the antenna) as appropriate for the number and needs of the customers currently attached. In any case the allocation MUST NOT exceed 64 bits in length. Geography provides distinguished meaning to the term 'home address'. The basic mechanism is a 2-bit interleave of the WGS-84 latitude / longitude values to minimize routing table size on 4-bit increments. While the prefix length MAY be established on any nibble boundary, the requirement for all service providers at that boundary to directly peer with all others will naturally limit the operational choices. Core routing SHOULD be based on best match of sparsely populated table using fixed first 3 bytes (FP + 20 bits) to find a region. Regional routing SHOULD be based on best match of moderately populated table using next 2-3 bytes to find neighborhood-site. for layer-3 exchanges to work there has to be a way to do source routing within a region to select ixc : rest of the system dst based routing simple directory lookup on flat 48 bit site id if so lec would dest route within region / src route to ixc ixc would dest route to next region dest lec would dest route within region Specification of the WGS-84 reference point SHOULD be the responsibility of the layer-1 service provider, and SHOULD represent the demarcation point of the layer-1 service. In the case where reference points overlap, the layer-1 service provider MUST coordinate the specification with the local jurisdiction. translation of deg.xxxxx into 44 bits of 2-bit interleaved binary the base angle is found by dividing 360 by the 2 ^ # of bits {ie: Microsoft Excel formula > = 360/(2^22) } 16 bits ~ 0.0054931640625 deg (grids 32763 lat - 65526 long) 18 bits ~ 0.001373291015625 deg (grids 131052 lat - 262104 long) 20 bits ~ 0.00034332275390625 deg (grids 524208 lat - 1048416 long) 22 bits ~ 0.0000858306884765625 deg (grids 2096832 lat - 4193664 long) Formation sequence: 1. for east/west (convert all west values to east - ie: 90w = 270e) 2. divide degrees (5 significant decimal places) by 0.0000858306884765625 (5 places of significance right of decimal in lat/long readings results in 1 m increment : within rounding error of 22 bit resolution : while 4 places of significance results in 11.1 m increments which is longer than the side ~ 9.5 m of the grid being identified) 3. convert each of the integers to 22-digit binary 4. north/south (set MSB for south) 5. interleave 2-bits lat, 2-bits long into 44-bit result (examples below) 6. convert result to 11-digit hex, insert : between digits 3-4 & 7-8 7. prepend FP 0x1 to form 12-digit hex as /48 prefix Format This document specifies the format for format prefix (FP) 0001 binary. | 4 | 44 | 16 | 64 bits | +---+---~---~---~---~~~~~-----+--------+---------------------------+ |FP | Region / Metro }{ Site | SLA | Interface ID | +---+---~---~---~---~~~~~-----+--------+---------------------------+ The geographic reference field MUST be calculated at 44-bits, but may be used in routing calculations on any 4-bit boundary. The approximate surface area covered by each grid value is provided in the table below. The size in meters is based on rounded values for the equatorial circumference and should only be used as a conceptual guideline. bits degrees nominal square scope sites -------------------------------------------------------------------- 4 -> 90.00000 10000 km octant 8 -> 22.50000 2500 km expanse 12 -> 5.625000 600 km zone 16 -> 1.406250 150 km region 20 -> 0.3515625 40 km metro 16777216 24 -> 0.087890625 10 km city 1048576 28 -> 0.02197265625 2.5 km locality 65536 32 -> 0.0054931640625 600 m neighborhood 4096 36 -> 0.001373291015625 150 m block 256 40 -> 0.00034332275390625 40 m lot 16 44 -> 0.0000858306884765625 10 m site 1 The location addressed as 1000:0000:0000/48 covers an area ~ 10 m on a side, centered at equator and the 0 meridian (Greenwich). Core routing table examples: Region lat long 2-bit interleave --------------------------------------------------------- W. Europe 080000 : 000000 -> 1080:0000:0000 S. Africa 260000 : 000000 -> 1848:0000:0000 NE Africa 030000 : 030000 -> 100F:0000:0000 E. Europe 080000 : 060000 -> 1092:0000:0000 C. Asia 030000 : 0C0000 -> 103C:0000:0000 E. Asia 060000 : 180000 -> 1168:0000:0000 Australia 260000 : 180000 -> 1968:0000:0000 Alaska 0C0000 : 240000 -> 12D0:0000:0000 NW US 080000 : 2B0000 -> 12A3:0000:0000 Central America 030000 : 2E0000 -> 123E:0000:0000 SE US 060000 : 300000 -> 1348:0000:0000 South America 260000 : 300000 -> 1B48:0000:0000 NW Africa 000000 : 3D0000 -> 1331:0000:0000 Airport location examples: MIA - 25.78 n 80.28 w 1341:A766:517A ATL - 33.63 n 84.42 w 1344:FFB9:B387 IAD - 38.93 n 77.45 w 134A:CBAF:8EEE JFK - 40.63 n 73.77 w 134E:3E86:26D5 ORD - 41.97 n 87.90 w 134C:5D7B:2586 DEN - 39.85 n 104.70 w 127D:1646:B7F8 SFO - 37.62 n 122.37 w 126A:8F32:3832 LAX - 33.93 n 118.40 w 126A:3383:1F34 SAN - 32.73 n 117.18 w 1267:C627:8442 ANC - 61.16 n 150.00 w 1299:D5DD:5D55 SYD - 33.97 s 151.17 e 185A:239B:332E NRT - 35.75 n 140.37 e 105A:47BD:0165 DEL - 28.55 n 77.01 e 1047:163C:474F CAI - 30.10 n 31.40 e 1045:5695:D80B CPT - 33.95 s 18.60 e 1848:3187:2688 CDG - 49.00 n 2.53 e 1080:8D78:30AD LHR - 51.47 n 0.350 w 13B7:3B48:4D42 GIG - 22.80 s 42.23 w 1B60:13F6:894C SCL - 33.38 s 70.78 w 1B47:DAEE:2BA5 MEX - 19.43 n 99.07 w 123E:5E43:435E N Pole - 90.00 n 0.00 e 1400:0000:0000 S Pole - 90.00 s 0.00 e 1C00:0000:0000 Routing protocol should only announce a short prefix if the router can get to the entire concatenation, if not it will need to announce specifics. The result is that at some point in the nibble hierarchy all service providers in a region have to share routes, and it becomes an engineering tradeoff between the size of the routing table, and the number of points where peering occurs. Basically expect tier-1's to run their core routers on a sparsely populated 8 bit table, their regional routers on a full population of the next 8 bits, with tier-2-3's looking at moderately populated 20 bit tables. Since 20 bits is nominally what tier-1's do today on a global scale I don't think this is out of line for scale or performance, and it bounds the problem to the set of providers where the multi-homing occurs. Site-Level Aggregation Identifier The SLA ID field is used by an individual organization to create its own local addressing hierarchy and to identify subnets. This is analogous to subnets in IPv4 except that each organization has a much greater number of subnets. The 16 bit SLA ID field support 65,535 individual subnets. Organizations may choose to either route their SLA ID "flat" (e.g., not create any logical relationship between the SLA identifiers that results in larger routing tables), or to create a two or more level hierarchy (that results in smaller routing tables) in the SLA ID field. The latter is shown as follows: | n | 16-n | 64 bits | +-----+------------+-------------------------------------+ |SLA1 | Subnet | Interface ID | +-----+------------+-------------------------------------+ | m |16-n-m | 64 bits | +----+-------+-------------------------------------+ |SLA2|Subnet | Interface ID | +----+-------+-------------------------------------+ The approach chosen for structuring an SLA ID field is the responsibility of the individual organization. The number of subnets supported by this address format should be sufficient for all but the most densely packed spaces. When the number of subnets exceeds 2 ^ 16 per 10 meter square of the earth's surface, alternative allocation mechanisms may be required. Interface ID Interface identifiers are used to identify interfaces on a link. They are required to be unique on that link. They may also be unique over a broader scope. In many cases an interfaces identifier will be the same or be based on the interface's link-layer address. Interface IDs used in the aggregatable global unicast address format are required to be 64 bits long and to be constructed in IEEE EUI-64 format [EUI-64]. These identifiers may have global scope when a global token (e.g. , IEEE 48bit MAC) is available or may have local scope where a global token is not available (e.g., serial links, tunnel end-points, etc.). The "u" bit (universal/local bit in IEEE EUI-64 terminology) in the EUI-64 identifier must be set correctly, as defined in [ARCH], to indicate global or local scope. The procedures for creating EUI-64 based Interface Identifiers is defined in [ARCH]. The details on forming interface identifiers is defined in the appropriate "IPv6 over " specification such as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. Technical Motivation The design choice for the size of the fields in the geographic address format was based on the need to separate the address allocation from the service provider (to address the scaling problems that mechanism creates when sites connect to multiple providers), and the need to preserve the subnet structure defined in [Aggregatable]. An additional benefit of separation is the ability of the site to switch providers without renumbering. Multi-site networks would internally advertise all the natural prefixes and let the [addr-selection] rules sort it out. This would result in systems selecting a source address that most closely matches the destination. Thus return traffic would naturally be directed toward the site boundary closest to the destination site (ie: traffic would traverse the public network as little as possible). Security Considerations Appendix Location measurements based on WGS84 World Geodetic System 84 provides a common geodetic reference : surface of an ellipsoid approximating the true shape of the Earth geoid. Origin = Earth's center of mass Z-axis = Conventional terrestrial pole - Bureau International de l'Heure X-axis = Intersection of the reference meridian plane and the equator Y-axis = right-handed Earth-fixed orthogonal coordinate system measured in the plane of the equator east of the X-axis equatorial radius = 6378137 m flattening = 1/298.257223563 ( f = (a-b)/a or b = a - (f*a) ) pole radius = 6356752 m equatorial circumference = 40075016 m pole circumference = 39940650 m pole is .33% smaller than equator References Significant portions of this text are directly copied from RFC 2374 for consistency. < Your references will be listed here. View "Page Layout" if they are not currently visible. > Acknowledgments Author's Addresses Tony Hain Cisco Systems 500 108th Ave. N.E. Suite 500 Bellevue, Wa. 98004 Email: alh-ietf@tndh.net From owner-multi6@ops.ietf.org Fri Jun 8 06:38:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08817 for ; Fri, 8 Jun 2001 06:38:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 158JeH-000CtQ-00 for multi6-data@psg.com; Fri, 08 Jun 2001 03:37:49 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 158JeG-000CtJ-00 for multi6@ops.ietf.org; Fri, 08 Jun 2001 03:37:48 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f58AbdH67974; Fri, 8 Jun 2001 12:37:39 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 8 Jun 2001 12:35:55 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Tony Hain cc: multi6@ops.ietf.org Subject: RE: Regionally aggregatable address space for multihoming In-Reply-To: Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 7 Jun 2001, Tony Hain wrote: > Here is the text of a very drafty-draft I have been working on for a couple > of weeks to address this specific issue. If things are not aligning right, > try putting the font in Courier 12. Comments please. - you may want to cut some text that isn't specific to this proposal - integer math would be easier than floating point math with 15 digits - if you move the 0 meridian to 30 deg west it won't cut through densely populated areas in Europe and Africa - why 2 bit interleave? one bit makes it possible to use arbitrary boundaries I made a small program to calculate the geographic address for any given location, but I got very different addresses for most things, although some worked. Have a look at http://www.muada.com/ipv6geo.php But the real question is: do we really want to use such a very direct relationship between addresses and geography? I see three major drawbacks: 1. This proposal uses 6.25% of the IPv6 address space and still some areas may have too few addresses. It is especially wasteful closer to the poles. There are only a few cities above 60 deg north or below 40 deg south, and these two areas use 44% of the address space in this proposal and 2.77% of the IPv6 address space if it is deployed. 2. The strictly geographic aggregation boundaries in this proposal won't fit current network topologies. So either the networks will have to be changed or the aggregation will be less successful. 3. Lots of renumbering: if strictly applied, this proposal means that moving a workstation from one end of a hallway to another implies renumbering. While the support for automatic renumbering are better in IPv6, it is still not something to take too lightly. Even if the renumbering itself is completely transparent to the user and applications, there is still the matter of the DNS. But what about this: in stead of using individual routes, we could encode routing information in bitmaps. A 150 km routing precission would take 2^16 = 64k bits = 8 kilobyte to encode. A reachability bitmap for all neighborhoods within a region would also take only 8k. But a 20 bit prefix would take 128k. So core routers would take 150 km precission bitmaps of the whole world from their peers. The next routing level would be the zone level, where 2.5 km precission bitmaps for a number of adjacent 600x600 km zones are exchanged. The next level would be able to handle the 10x10 m sites. This would also permit very fast routing updates because reachability information can be updated with just a few AND and OR operations on the bitmaps. From owner-multi6@ops.ietf.org Fri Jun 8 10:11:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12946 for ; Fri, 8 Jun 2001 10:11:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 158Mxe-000M64-00 for multi6-data@psg.com; Fri, 08 Jun 2001 07:10:02 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.16 #1) id 158Mxd-000M5p-00 for multi6@ops.ietf.org; Fri, 08 Jun 2001 07:10:01 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id 38E57882; Fri, 8 Jun 2001 16:09:56 +0200 (CEST) To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming References: From: Sean Doran Date: 08 Jun 2001 16:09:54 +0200 In-Reply-To: (Iljitsch van Beijnum's message of "Tue, 5 Jun 2001 11:33:00 +0200 (West-Europa (zomertijd))") Message-ID: <52ae3jawr1.fsf@sean.ebone.net> Lines: 36 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch van Beijnum writes: > All networks announce their customer's routes everywhere, but peers simply > filter out these announcements on exchange points that do not fall within > their idea of the region. So what happens in the case where a site connects to a network which does not actually connect to the local exchange point at all? X-Corp acquires geographically-assigned addresses from a local registry, then buys transit from ANet and BNet; ANet is connected to the local IX but BNet is not. How shall BNet advertise reachability to X-Corp? ANet and CNet, both present at the local IX, have a commercial falling-out. Or a fibre cut. Or the IX fails. Or something. This leads to a long-term outage in _direct_ local connectivity between ANet and CNet; however ANet purchases backup connectivity from DNet, one of CNet's peers. Y-Corp, a customer of CNet in another city, now wants to send traffic to X-Corp (and vice-versa). How can this happen? The question in a nutshell, is: how does one deal with "exception routing" in the event one cannot guarantee a always fully-interconnected geographical area? That is, if one draws an addressing abstraction boundary around a geographical area rather than a topological area, must one/can one/how can one guarantee that the enclosed area can always be abstracted? This is the riddle of the CIDR Sphinx. Sean. From owner-multi6@ops.ietf.org Fri Jun 8 10:50:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13529 for ; Fri, 8 Jun 2001 10:50:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 158NZ3-000MV5-00 for multi6-data@psg.com; Fri, 08 Jun 2001 07:48:41 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.16 #1) id 158NZ2-000MUz-00 for multi6@ops.ietf.org; Fri, 08 Jun 2001 07:48:40 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id 683FF882; Fri, 8 Jun 2001 16:48:38 +0200 (CEST) To: , multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming References: From: Sean Doran Date: 08 Jun 2001 16:48:38 +0200 In-Reply-To: ("Tony Hain"'s message of "Thu, 7 Jun 2001 13:55:23 -0700") Message-ID: <5266e7auyh.fsf@sean.ebone.net> Lines: 122 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit "Tony Hain" writes: Tony, thanks for the first rev of a draft! I have some comments and questions that I hope may help improve it. > sites that connect to metropolitan scale exchanges. Do such exchanges exist? I'm curious, since I haven't run into any, even in Stockholm, where fibre is very close to free. > Sites will have the choice to connect to either type of > aggregation entity. Can sites connect to both? If no, is that a feature or a drawback? > Any provider announcing a short prefix SHOULD be able to > deliver packets to anywhere in the region, either > directly or through other arrangements. In the case > where a service provider does not interconnect with > others in its region it MUST advertise the longer > prefixes associated with its customers. What if the provider is connected and fully peered with all the other networks using addresses from the same aggregate, but is partitioned from some or all of them for a period of time? (An interesting thinking exercise is trying to figure out how networks multihomed at other geographical exchanges, and having multiple transit arrangements across those exchanges, can determine which long-haul provider should be used to reach a network that is ordinarily abstracted behind an aggregate covering all the networks in a given geographical area/surrounding a given IX. You have discovered one of the hard questions already, viz.: > Another issue is the business model being flipped from > the current destination's ISP choice determines sources > routing; to one of source's ISP choice determines at > least its first hop. In other words, "how does the source make a correct choice of next-hop?". Let us know what you come up with, or if someone else has properly solved this á la GSE or Ohta-multi-prefix.) > This address allocation mechanism SHOULD NOT be used on a dial access > network pop, as scaling routes to sites attached this way are best addressed > through provider based allocations consistent with Aggregatable [RFC 2374]. Why not? How do multihoming entities who offer both fixed-line and dial access accomodate this? How far does this reach? Does this include a dialup pool in a site singly-connected to a provider? > for layer-3 exchanges to work there has to be a way to do source routing > within a region to select ixc : rest of the system dst based routing > simple directory lookup on flat 48 bit site id > if so lec would dest route within region / src route to ixc > ixc would dest route to next region > dest lec would dest route within region IXC and LEC are Americanisms, and moreover are an artefact of a regulatory regime which is NOT global. It's probably a good idea to avoid terms like these in a document which is designed to work for the whole Internet. :-) - -- If a large U.S. network has a number of peers and paying transit customers in W. Europe (for example), and each of these networks have customers that are using both provider-assigned and IX-assigned addresses, how should large U.S. network decide which of the customers to send traffic to, if they are announcing only an aggregate of: > W. Europe 080000 : 000000 -> 1080:0000:0000 or > LHR - 51.47 n 0.350 w 13B7:3B48:4D42 ? Does your apparent (post hoc) answer: > Routing protocol should only announce a short prefix if the router can get > to the entire concatenation, if not it will need to announce specifics. mean that the U.S. network's x-Atlantic customers must announce the individual customer prefixes learned at the LHR exchange, and not announce the aggregate for LHR or for W. Europe? If this U.S. network has several competitors for transit sold to networks across the Atlantic, as is the case today, what becomes of the idea of announcing 1080:0000:0000 to anywhere? (Think of what they would do to be able to announce 1080:0000:0000 to -- competitors with no European customers -- customers who are multihomed to competitors with European customers -- customers who are multihomed to European networks -- customers who ARE European networks, but who operate in only one part of W. Europe etc. Then think of what happens when the connectivity to one or more of their trans-Atlantic customers fails. This happens sometimes...) BTW, if you are doing updates to your draft, this is not very draft-y-language: :-) > Since 20 bits is nominally what tier-1's do today > on a global scale I don't think this is out of line for scale or > performance, and it bounds the problem to the set of providers where the > multi-homing occurs. Sean. From owner-multi6@ops.ietf.org Fri Jun 8 10:57:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13739 for ; Fri, 8 Jun 2001 10:57:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 158Nfl-000MZU-00 for multi6-data@psg.com; Fri, 08 Jun 2001 07:55:37 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.16 #1) id 158Nfk-000MZN-00 for multi6@ops.ietf.org; Fri, 08 Jun 2001 07:55:36 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id 03399882; Fri, 8 Jun 2001 16:55:34 +0200 (CEST) To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming References: From: Sean Doran Date: 08 Jun 2001 16:55:34 +0200 In-Reply-To: (Iljitsch van Beijnum's message of "Fri, 8 Jun 2001 12:35:55 +0200 (West-Europa (zomertijd))") Message-ID: <521yovaumx.fsf@sean.ebone.net> Lines: 17 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch van Beijnum writes: > But what about this: in stead of using individual routes, we could encode > routing information in bitmaps It would be nice if you would write up a draft proposing this. There are theoretical strengths in map-exchange routing systems, and such systems benefit from well-designed packet-header encodings which express a path through a topology discovered through the exchange of maps among routers. Do you think that a scheme to encode physical-proximity can coexist with a scheme to encode topological-proximity? That could be a handy feature... Sean. From owner-multi6@ops.ietf.org Fri Jun 8 11:05:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13866 for ; Fri, 8 Jun 2001 11:05:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 158NnA-000MeT-00 for multi6-data@psg.com; Fri, 08 Jun 2001 08:03:16 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 158Nn9-000MeM-00 for multi6@ops.ietf.org; Fri, 08 Jun 2001 08:03:15 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f58F39H68287; Fri, 8 Jun 2001 17:03:09 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 8 Jun 2001 17:01:20 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Sean Doran cc: multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming In-Reply-To: <521yovaumx.fsf@sean.ebone.net> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On 8 Jun 2001, Sean Doran wrote: > > But what about this: in stead of using individual routes, we could encode > > routing information in bitmaps > It would be nice if you would write up a draft proposing this. Ok. > There are theoretical strengths in map-exchange routing > systems, and such systems benefit from well-designed > packet-header encodings which express a path through a > topology discovered through the exchange of maps among routers. > Do you think that a scheme to encode physical-proximity > can coexist with a scheme to encode topological-proximity? > That could be a handy feature... Do you mean both the physical and topological proximity of the same entity, or just physical proximity for some entities and topological proximity for others? From owner-multi6@ops.ietf.org Fri Jun 8 11:09:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13936 for ; Fri, 8 Jun 2001 11:09:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 158Nr0-000Mgj-00 for multi6-data@psg.com; Fri, 08 Jun 2001 08:07:14 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.16 #1) id 158Nqz-000Mgc-00 for multi6@ops.ietf.org; Fri, 08 Jun 2001 08:07:13 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id 1CCD0882; Fri, 8 Jun 2001 17:07:12 +0200 (CEST) To: iljitsch@muada.com, smd@ebone.net Subject: Re: Regionally aggregatable address space for multihoming Cc: multi6@ops.ietf.org Message-Id: <20010608150712.1CCD0882@sean.ebone.net> Date: Fri, 8 Jun 2001 17:07:12 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk | Do you mean both the physical and topological proximity of the same entity, | or just physical proximity for some entities and topological proximity for | others? Well, how about both? I really meant "either" when I asked the question, but if a hybrid can be proposed that simultaneously describes a position in physical space and a position in the network, obviously that would be interesting! Sean. From owner-multi6@ops.ietf.org Fri Jun 8 11:48:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14851 for ; Fri, 8 Jun 2001 11:48:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 158OSG-000NC4-00 for multi6-data@psg.com; Fri, 08 Jun 2001 08:45:44 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 158OSF-000NBy-00 for multi6@ops.ietf.org; Fri, 08 Jun 2001 08:45:44 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f58FjfH68363; Fri, 8 Jun 2001 17:45:41 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 8 Jun 2001 17:43:51 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Sean Doran cc: multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming In-Reply-To: <52ae3jawr1.fsf@sean.ebone.net> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On 8 Jun 2001, Sean Doran wrote: > > All networks announce their customer's routes everywhere, but peers simply > > filter out these announcements on exchange points that do not fall within > > their idea of the region. > So what happens in the case where a site connects to a > network which does not actually connect to the local > exchange point at all? > X-Corp acquires geographically-assigned addresses from > a local registry, then buys transit from ANet and BNet; > ANet is connected to the local IX but BNet is not. > How shall BNet advertise reachability to X-Corp? Just as I said: both ANet and BNet announce the route to X-Corp on every exchange point anywhere in the world where they are present. However, other networks will probably only accept these routes at the regional exchange point and a few others in neighboring regions. So if BNet isn't present at these exchange points other networks will have to accept those routes elsewhere, which doesn't help the whole aggregation idea but guarantees connectivity. > ANet and CNet, both present at the local IX, have a > commercial falling-out. Or a fibre cut. Or the IX fails. > Or something. This leads to a long-term outage in > _direct_ local connectivity between ANet and CNet; however > ANet purchases backup connectivity from DNet, one of > CNet's peers. Y-Corp, a customer of CNet in another city, > now wants to send traffic to X-Corp (and vice-versa). > How can this happen? Since X-Corp is also a customer of DNet (through ANet) DNet will also carry the route everywhere. Also, if BNet sells full connectivity there will be some point where traffic from CNet can reach BNet. So X-Corp is still fully connected and can receive traffic from Y-Corp over Y-Corp -> CNet -> DNet -> ANet -> X-Corp or Y-Corp -> CNet -> ??? -> BNet -> X-Corp. > The question in a nutshell, is: how does one deal with > "exception routing" in the event one cannot guarantee a > always fully-interconnected geographical area? The answer is that the geographical area MUST always be fully interconnected. This is easily accomplished by just increasing the area until it is. > That is, if one draws an addressing abstraction boundary > around a geographical area rather than a topological area, > must one/can one/how can one guarantee that the enclosed > area can always be abstracted? I think you assume a fixed relationship between the area where the addresses are used and the area where the routes are known. The only relationship necessary is that the former falls within the latter. Obviously, the geographic region in which the addresses may be used needs to be well-defined and must be observed by everyone. But, every network should be free to decide where specific routes for a region may live. This can be just the region where the addresses are used and one other for redundancy, or the whole continent or even the whole world. Since all networks carry customer routes everywhere, there is no need for networks to connect within the target region. A network may pick up routes for a multihomed New York business in Sydney if it so desires. So even if this network only connects to the transit networks for the New York business in Sydney, there is still connectivity. But if for some strange reason the network in Sydney has a customer in New York, the other networks will very likely ignore this route in Sydney, because it falls outside their idea of the area where specific routes to New York addresses are needed. This is a somewhat unlikely situation, but it can still work if the other networks make an exception and accept the New York route in Sydney from this network. It all gets somewhat complex but the good thing is it should be possible to deploy this type of aggregation within IPv4/BGP4 without breaking anything as long as multihomed addresses are assigned geographically. The only real problem is that of transit networks that are so large even the number of routes from customers and customers of customers becomes too large for the routers. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Fri Jun 8 13:43:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18023 for ; Fri, 8 Jun 2001 13:43:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 158QHu-000OzP-00 for multi6-data@psg.com; Fri, 08 Jun 2001 10:43:10 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.16 #1) id 158QHt-000Oz9-00 for multi6@ops.ietf.org; Fri, 08 Jun 2001 10:43:09 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 08 Jun 2001 10:43:01 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 677CE9A1FED948598261ED456BA3B9E8 for plus 2 more; Fri, 08 Jun 2001 10:43:00 -0700 Reply-To: From: "Tony Hain" To: "Iljitsch van Beijnum" , "Tony Hain" Cc: Subject: RE: Regionally aggregatable address space for multihoming Date: Fri, 8 Jun 2001 10:43:00 -0700 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal X-SLUIDL: 455CAD6B-BEBC42C8-BA9A8E58-1FC56C08 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This proposal is not attempting to provide the optimal 'one and only' solution to addressing in the global Internet, and I specifically don't care about waste since I know off the top that ~ 2/3 is unusable. What it is trying to do is provide a specific tool for addressing the impact on routing by multi-homed sites. It does not require renumbering as devices move, unless the public demarcation at layer 1 changes as a result. It may not map well with current topologies, though I would like to have some operators show specifically where it breaks down. -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent: Friday, June 08, 2001 3:36 AM To: Tony Hain Cc: multi6@ops.ietf.org Subject: RE: Regionally aggregatable address space for multihoming On Thu, 7 Jun 2001, Tony Hain wrote: > Here is the text of a very drafty-draft I have been working on for a couple > of weeks to address this specific issue. If things are not aligning right, > try putting the font in Courier 12. Comments please. - you may want to cut some text that isn't specific to this proposal - integer math would be easier than floating point math with 15 digits - if you move the 0 meridian to 30 deg west it won't cut through densely populated areas in Europe and Africa - why 2 bit interleave? one bit makes it possible to use arbitrary boundaries I made a small program to calculate the geographic address for any given location, but I got very different addresses for most things, although some worked. Have a look at http://www.muada.com/ipv6geo.php But the real question is: do we really want to use such a very direct relationship between addresses and geography? I see three major drawbacks: 1. This proposal uses 6.25% of the IPv6 address space and still some areas may have too few addresses. It is especially wasteful closer to the poles. There are only a few cities above 60 deg north or below 40 deg south, and these two areas use 44% of the address space in this proposal and 2.77% of the IPv6 address space if it is deployed. 2. The strictly geographic aggregation boundaries in this proposal won't fit current network topologies. So either the networks will have to be changed or the aggregation will be less successful. 3. Lots of renumbering: if strictly applied, this proposal means that moving a workstation from one end of a hallway to another implies renumbering. While the support for automatic renumbering are better in IPv6, it is still not something to take too lightly. Even if the renumbering itself is completely transparent to the user and applications, there is still the matter of the DNS. But what about this: in stead of using individual routes, we could encode routing information in bitmaps. A 150 km routing precission would take 2^16 = 64k bits = 8 kilobyte to encode. A reachability bitmap for all neighborhoods within a region would also take only 8k. But a 20 bit prefix would take 128k. So core routers would take 150 km precission bitmaps of the whole world from their peers. The next routing level would be the zone level, where 2.5 km precission bitmaps for a number of adjacent 600x600 km zones are exchanged. The next level would be able to handle the 10x10 m sites. This would also permit very fast routing updates because reachability information can be updated with just a few AND and OR operations on the bitmaps. From owner-multi6@ops.ietf.org Fri Jun 8 16:23:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20211 for ; Fri, 8 Jun 2001 16:23:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 158SkD-0008Bl-00 for multi6-data@psg.com; Fri, 08 Jun 2001 13:20:33 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.16 #1) id 158SkB-0008Bf-00 for multi6@ops.ietf.org; Fri, 08 Jun 2001 13:20:32 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 08 Jun 2001 13:20:15 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 8AB754A0E8A7457A9109F2D12B947AF7 for plus 1 more; Fri, 08 Jun 2001 13:20:15 -0700 Reply-To: From: "Tony Hain" To: "Sean Doran" , Subject: RE: Regionally aggregatable address space for multihoming Date: Fri, 8 Jun 2001 13:20:14 -0700 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <5266e7auyh.fsf@sean.ebone.net> Importance: Normal X-SLUIDL: 7B5B3084-6A7745CD-93C1CE79-CCFA30BC Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Sean Doran wrote: > Tony, thanks for the first rev of a draft! I have some > comments and questions that I hope may help improve it. The more the merrier. >> sites that connect to metropolitan scale exchanges. > >Do such exchanges exist? I'm curious, since I haven't run into any, >even in Stockholm, where fibre is very close to free. That wording was directly out of the aggregatable draft and I didn't have a good reason to change it. In some ways I would consider at least the MSN-UK & MSN-ASIA sites as directly connected to exchanges. At least the last I knew they were co-lo with the exchange but may have had a telco fronting for the physical exchange port. >> Sites will have the choice to connect to either type of >> aggregation entity. > >Can sites connect to both? If no, is that a feature or a drawback? There should be no problem with connecting to both. As I worked through this their inbound traffic would take whichever path was shorter from any given source, and it would be up to them which direction they sent the outbound. >> Any provider announcing a short prefix SHOULD be able to >> deliver packets to anywhere in the region, either >> directly or through other arrangements. In the case >> where a service provider does not interconnect with >> others in its region it MUST advertise the longer >> prefixes associated with its customers. > >What if the provider is connected and fully peered with >all the other networks using addresses from the same >aggregate, but is partitioned from some or all of them for >a period of time? This would require the obvious; either longer prefixes need to be announced, or there will be black holes. This is no different from today where someone announces access to a partitioned network. >(An interesting thinking exercise is trying to figure out >how networks multihomed at other geographical exchanges, >and having multiple transit arrangements across those >exchanges, can determine which long-haul provider should >be used to reach a network that is ordinarily abstracted >behind an aggregate covering all the networks in a given >geographical area/surrounding a given IX. You have >discovered one of the hard questions already, viz.: Yes this is an area that needs much more detail. At a crude level it can be viewed in the context of the PSTN where the transit provider is 'managed' by the originator. Basically it would be up to the site network manager to decide which transit provider he would be sending traffic to for various parts of the world. If something partitions the result is no different than today. Either the network that can't get there anymore has alternate arrangements for transit, or the traffic is black holed. >> Another issue is the business model being flipped from >> the current destination's ISP choice determines sources >> routing; to one of source's ISP choice determines at >> least its first hop. > >In other words, "how does the source make a correct >choice of next-hop?". What does 'correct' mean? If I have transit agreements with ISP-ABC & ISP-XYZ, I am either getting default service from them, or the global default-free table. If I have the table and they both claim they can get to the destination region, or I am simply have default, then it is up to me as the source where I send the bits. With provider-based addresses the routing system will shunt me to the shortest AS path to that destination, but with this scheme the provider I hand the bits to would send them along its preferred path to the region IX before deciding which local provider to deliver them through. >Let us know what you come up with, or if someone else has >properly solved this a la GSE or Ohta-multi-prefix.) The question I keep coming back to is 'who is deciding what is right, the service provider or the site manager as the customer?' It clearly has to be one of those two and not the protocol designer, but individual perspective has a big impact here. I would argue that the customer would ultimately vote with his wallet to define 'right and proper', so the service providers will in turn beat on the protocol designers to get the tools to deliver that. Minimizing the operational costs of the service provider is certainly one of the components of 'right', but each scheme has to be balanced against the costs it imposes back on the customer site. >> This address allocation mechanism SHOULD NOT be used on a dial access >> network pop, as scaling routes to sites attached this way are best >> addressed through provider based allocations consistent with >> Aggregatable [RFC 2374]. > >Why not? For one the location of the endpoint is unknown. For another if a dial-pop were scaled to handle 10,000 sites it would have to subsume the neighboring addresses in the 2.5km square. Since dial-pops tend to be located in dense areas using them with geo addresses would have the maximum negative effect. >How do multihoming entities who offer both fixed-line and dial access >accomodate this? I struggled with this one until I realized that it doesn't matter in practice. If the dial path were really just an intermittent connection between routers at the same service provider then it would be reasonable and expected that the geo prefix would be used on both and the site would simply announce that as its prefix upstream. Interface metrics would bias the providers IGP to do the right thing. If the multi-homed site has both fixed-line and dial to different providers, they would get one of these prefixes for the fixed-line, and a provider aggregate prefix for the dial. I would expect local policy to prefer the fixed-line prefix, but there is no protocol issue with having both. The place this differs from today is that if one of those paths failed the hosts would have to initiate mobile IP to maintain any existing connections. >How far does this reach? Does this include a dialup pool >in a site singly-connected to a provider? I would argue that it applies to anything where the real site location and its topology is unknown. At first I had mobile systems in this same category until I decided that the number of active nodes on a cell is low relative to a dial-pop, and that providers are more likely to allocate a /56 in the mobile device environment. In that case it would be feasible for the cell to hand out prefixes based on the tower location, where the large dial-pop it would not. If my assumption is wrong then I need to move mobile back to the provider allocation side. >> for layer-3 exchanges to work there has to be a way to do source >> routing within a region to select ixc : rest of the system dst based >> routing simple directory lookup on flat 48 bit site id >> if so lec would dest route within region / src route to ixc >> ixc would dest route to next region >> dest lec would dest route within region > >IXC and LEC are Americanisms, and moreover are an artefact >of a regulatory regime which is NOT global. It's probably >a good idea to avoid terms like these in a document which >is designed to work for the whole Internet. :-) This is an artifact of the drafty nature of random thoughts. I welcome more appropriate terms since transit would apply in both the local and long haul cases. I am not sure how applicable this text is to reality though, as it resulted from a conversation about layer-3 exchanges. If all the exchanges are layer-2 there is no magic required, but for a site to influence policy at a layer-3 IX there would have to be something like source routing. - -- >If a large U.S. network has a number of peers and >paying transit customers in W. Europe (for example), >and each of these networks have customers that are using >both provider-assigned and IX-assigned addresses, >how should large U.S. network decide which of the >customers to send traffic to, if they are announcing only >an aggregate of: > >> W. Europe 080000 : 000000 -> 1080:0000:0000 > >or > >> LHR - 51.47 n 0.350 w 13B7:3B48:4D42 > >? This is an artifact of trying to use location info that would be easy for the layer-1 installer to obtain mixed with text strings that have political context. There would have to be at least 2 prefix announcements for the political entity known as W. Europe to cover each side of the meridian. Clearly the text before that table needs to make it clearer that they are conceptual examples rather than entries that cover the entire named region. In fact one of the things I was trying to do in the table preceding that one was to come up with names for the scopes that had no political meaning. >Does your apparent (post hoc) answer: > >> Routing protocol should only announce a short prefix if the router >> can get to the entire concatenation, if not it will need to announce >> specifics. > >mean that the U.S. network's x-Atlantic customers must >announce the individual customer prefixes learned at the >LHR exchange, and not announce the aggregate for LHR or >for W. Europe? I am not sure I understand the question, but for example if a site west of LHR was accessible via both its geo and provider addresses, the announcement toward the US would include the prefix for its provider and the prefix that covered W. Europe west of the meridian (without doing the math, probably 1380::). >If this U.S. network has several competitors for transit >sold to networks across the Atlantic, as is the case today, >what becomes of the idea of announcing 1080:0000:0000 to anywhere? I need a picture to understand the question. Basically today's business models are built around the concept that a site works with ISPs to arrange traffic preferences toward itself. With this scheme the business model would flip so that a site arranges for best carriage of its outbound traffic into a region. If the network the site subscribes to does not have direct access to 1080:: it needs to subscribe to a transit that will get there. >(Think of what they would do to be able to announce 1080:0000:0000 to > -- competitors with no European customers > -- customers who are multihomed to competitors > with European customers > -- customers who are multihomed to European networks > -- customers who ARE European networks, but who > operate in only one part of W. Europe > etc. >Then think of what happens when the connectivity to one or more of >their trans-Atlantic customers fails. This happens sometimes...) Again I am missing some context here. If a network were providing transit to 1080:: it would need to announce that, but if it only had a specific customer set and didn't intend to provide access to all of 1080:: then it would need to announce the specifics. I am getting a feeling that this question is wrapped tightly around a business model where a site would arrange for transit services toward itself via a specific provider. There is nothing wrong with that, but in that case provider based addresses make more sense. With IPv6 there is no reason a site is restricted to a single prefix so there is no problem with having prefixes from a US-based and a European-based provider as well as the location-based one. Address selection rules will cause the longest match src/dst pair to be used. >BTW, if you are doing updates to your draft, this is not >very draft-y-language: :-) >> Since 20 bits is nominally what tier-1's do today >> on a global scale I don't think this is out of line for scale or >> performance, and it bounds the problem to the set of providers where >the multi-homing occurs. More random thoughts that need to be cleaned up before this goes in as an I-D. From owner-multi6@ops.ietf.org Mon Jun 11 08:57:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09048 for ; Mon, 11 Jun 2001 08:57:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159RD0-000PTR-00 for multi6-data@psg.com; Mon, 11 Jun 2001 05:54:18 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 159RCz-000PTJ-00 for multi6@ops.ietf.org; Mon, 11 Jun 2001 05:54:17 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f5BCrwH74753; Mon, 11 Jun 2001 14:54:09 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 11 Jun 2001 14:50:17 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Tony Hain cc: multi6@ops.ietf.org Subject: RE: Regionally aggregatable address space for multihoming In-Reply-To: Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 8 Jun 2001, Tony Hain wrote: > This proposal is not attempting to provide the optimal 'one and only' > solution to addressing in the global Internet, and I specifically don't care > about waste since I know off the top that ~ 2/3 is unusable. What it is > trying to do is provide a specific tool for addressing the impact on routing > by multi-homed sites. It does not require renumbering as devices move, > unless the public demarcation at layer 1 changes as a result. It may not map > well with current topologies, though I would like to have some operators > show specifically where it breaks down. Ok, lets not dwell on the wasted address space or incidental renumbering. The most important problem is the bad fit with existing topologies. What we really need to eveluate this is a map with all the prefixes drawn in. In the mean time, I believe there WILL be problems, the only question is how big they'll be. Since it is impossible to route strictly on geography alone (even if this were a possibility, then there would only be one route so this would defeat the purpose of being multihomed), my question is: why use such a strict relationship between prefix and geography? From owner-multi6@ops.ietf.org Mon Jun 11 12:23:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14002 for ; Mon, 11 Jun 2001 12:23:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159UTU-0002f1-00 for multi6-data@psg.com; Mon, 11 Jun 2001 09:23:32 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.16 #1) id 159UTT-0002eq-00 for multi6@ops.ietf.org; Mon, 11 Jun 2001 09:23:31 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 11 Jun 2001 09:23:24 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id C8D26390953F49CB84028C7C19E6DF09 for plus 2 more; Mon, 11 Jun 2001 09:23:22 -0700 Reply-To: From: "Tony Hain" To: "Iljitsch van Beijnum" , "Tony Hain" Cc: Subject: RE: Regionally aggregatable address space for multihoming Date: Mon, 11 Jun 2001 09:23:21 -0700 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal X-SLUIDL: DA3E9A0A-3C974EAD-A82E93C0-852C9C38 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I believe there WILL be problems, the only question is how big > they'll be. I absolutely believe there will be work required to match what gets passed in the routing tables with the desired traffic flows over the current topology, or to modify the topology to align with this. If doing work constitutes a problem then I guess your statement covers it. > Since it is impossible to route strictly on geography alone (even if > this were a possibility, then there would only be one route so this > would defeat the purpose of being multihomed), my question is: why > use such a strict relationship between prefix and geography? Just like it is impossible to run dial modems faster than 1200bps, TCP faster than 2 Mbps, or voice over a packet infrastructure. It is not possible until we figure out how to do it. Note I am not proposing that routers know about geography, but that a prefix they know how to deal with be constructed out of something a telco installer can use to uniquely identify a demarc. For any given flow today there is only one route, the one defined by EGP/IGP metrics. The fact that others exist is irrelevant until this one goes away and a recomputation is done. With this prefix scheme (just like any existing IPv4 one) there can be an unlimited number of parallel paths to the destination and whichever one the source chooses is 'the only one' until the source (or some intermediate router) chooses a different one. The difference with this scheme is that the prefixes are structured on a global scale so they aggregate well outside the scope of local provider interactions. The only question I see as a sticking point is; will transit providers be willing to charge for ingress offered loads in addition to the egress they charge for today? If so they will be happy because they are getting paid to carry traffic, if not they will really be against this since it would cause them to carry traffic they are not getting paid for. Tony From owner-multi6@ops.ietf.org Mon Jun 11 14:21:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16293 for ; Mon, 11 Jun 2001 14:21:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159WIv-0004Xz-00 for multi6-data@psg.com; Mon, 11 Jun 2001 11:20:45 -0700 Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by psg.com with esmtp (Exim 3.16 #1) id 159WIu-0004XK-00 for multi6@ops.ietf.org; Mon, 11 Jun 2001 11:20:44 -0700 Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA18786; Mon, 11 Jun 2001 11:20:05 -0700 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA16982; Mon, 11 Jun 2001 11:20:09 -0700 Message-ID: <3B24F83E.B3860EF3@hursley.ibm.com> Date: Mon, 11 Jun 2001 11:56:30 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Sean Doran , multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: ... > > The question in a nutshell, is: how does one deal with > > "exception routing" in the event one cannot guarantee a > > always fully-interconnected geographical area? > > The answer is that the geographical area MUST always be fully > interconnected. This is easily accomplished by just increasing the area until > it is. This is my problem with this proposal, as it has been with every geo addressing proposal over the last 5 years. Because of this fact (you have to increase the area covered until it is big enough to be flat-routable), I think that every geo area would reproduce exactly the problem of entropy and default-route-table bloat that we have in today's tiny little Internet. So I have little confidence that this solution is scaleable to the 10 billion node Internet. I think the only geo solutions that scale will be ones that involve either encapsulation or goop-rewriting. Brian From owner-multi6@ops.ietf.org Mon Jun 11 15:34:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17470 for ; Mon, 11 Jun 2001 15:34:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159XSD-0005aF-00 for multi6-data@psg.com; Mon, 11 Jun 2001 12:34:25 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 159XSC-0005Zv-00 for multi6@ops.ietf.org; Mon, 11 Jun 2001 12:34:24 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f5BJYLH75171; Mon, 11 Jun 2001 21:34:21 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 11 Jun 2001 21:30:24 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Brian E Carpenter cc: Sean Doran , multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming In-Reply-To: <3B24F83E.B3860EF3@hursley.ibm.com> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 11 Jun 2001, Brian E Carpenter wrote: > This is my problem with this proposal, as it has been with every geo addressing > proposal over the last 5 years. > Because of this fact (you have to increase the area covered until it is > big enough to be flat-routable), I think that every geo area would > reproduce exactly the problem of entropy and default-route-table bloat > that we have in today's tiny little Internet. When the number of routes per area grows, it is likely that the areas themselves shrink, if only for this very reason. I'm not saying geographic aggregation will magically make all the problems go away. However, it will buy us two or three orders of magnitude, which is nothing to sneeze at. > So I have little confidence > that this solution is scaleable to the 10 billion node Internet. The number of nodes is not very relevant: you can fit 10 billion many, many times inside the /48 a single customer would get. All that matters is the number or routes and the resources needed to transmit, process and store each route. In IPv4 aggregation isn't used to its full potential, for historical and address depletion reasons (besides some ignorance) and because of multihoming. In IPv6 it will be much simpler to agressively aggregate, because there is little need to give ISPs only small blocks of address space and have them come back for more as they grow. So the main threat to the routing table are the multihomed networks. It would be nice to know how many people or business will be multihomed in the future, but there are no real figures. We only know that the number is still relatively small but rising fast. I think we can get away with assuming an upper limit on multihoming of 1% of the population. This is something like 10% of all businesses. Obviously anything that does better than 1% would be great, but if we can achieve 1% we'll have bought a lot of time to think about the other 99%. With a world population of 10 billion looming, this would be 100 million routes to multihomed networks. This is too much for any single router. However, if we can break up the world into 100 regions, this would only be 1 (or rather 2) million per region, which is still a lot but managable, if not now at least in the near future. Combined with more efficient ways to store and transmit routes, this should work for a long time to come. The current routing paradigm is to store a lot of information about each individual route, since aggregation makes sure there aren't very many similar routes. But in a few years (decades) when 1% of New York City is multihomed, this means more than 200k routes (to 100k destinations) within a fairly small geographic region. If this market is serviced by 20 ISPs this means 10,000 routes per ISP, each taking more than 100 bytes of memory, even though these routes are likely to be nearly identical. If we assign all these addresses out of a single 131072 * /48 block and then each ISP uses a bitmap attached to the aggregated /31 to announce whether any of those /48's is connected to them, it only takes somewhat over 100 bytes for the /31 + a 16k bitmap for a total of ~16500 bytes in stead of more than a megabyte. Another ISP that peers with all of them will only get some 330 kilobyte of routing information in stead of 20 MB. My idea for geographical aggregation can be deployed in the current IPv4/BGP4 Internet without breaking anything. The only thing that has to be done is divvy up the world in regions and assign address space to multihomed networks within the same region from an aggregatable block. Then networks can start to filter out routes from blocks far away without the risk of suboptimal routing to multihomed networks closer by if and when they want, with potential benefits of new route storage paradigms in the future. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Jun 11 16:16:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18176 for ; Mon, 11 Jun 2001 16:16:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159Y7K-00069J-00 for multi6-data@psg.com; Mon, 11 Jun 2001 13:16:54 -0700 Received: from garlic.amaranth.net ([216.235.243.195]) by psg.com with esmtp (Exim 3.16 #1) id 159Y7J-00069D-00 for multi6@ops.ietf.org; Mon, 11 Jun 2001 13:16:53 -0700 Received: from yarrow.senie.com (amaranth.ne.mediaone.net [24.218.3.83] (may be forged)) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f5BKGpj16753 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 11 Jun 2001 16:16:51 -0400 Message-Id: <5.1.0.14.2.20010611160635.00a2d590@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Jun 2001 16:16:46 -0400 To: multi6@ops.ietf.org From: Daniel Senie Subject: Re: Regionally aggregatable address space for multihoming In-Reply-To: References: <3B24F83E.B3860EF3@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 03:30 PM 6/11/01, Iljitsch van Beijnum wrote: >So the main threat to the routing table are the multihomed networks. It would >be nice to know how many people or business will be multihomed in the future, >but there are no real figures. Assume somewhere approaching 100%. Businesses are relying on the Internet for mission critical applications. They want ways to not be out-of-business in the event of anything from a failure within the cables running down the telephone poles to a routing architecture or peering collapse at one of their upstreams (e.g. PSI and C&W snipping ties with each other). Whatever solution, we need to find methods that at least PERMIT every business to be multi-homed. Yes, this is a hard problem to solve. I believe that's the scope of the problem, though, and we need to find a better answer than trying to convince people they should not multihome. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-multi6@ops.ietf.org Mon Jun 11 16:47:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18669 for ; Mon, 11 Jun 2001 16:47:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159YaP-0006jA-00 for multi6-data@psg.com; Mon, 11 Jun 2001 13:46:57 -0700 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.16 #1) id 159YaO-0006iU-00 for multi6@ops.ietf.org; Mon, 11 Jun 2001 13:46:56 -0700 Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA30518; Mon, 11 Jun 2001 21:46:23 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA43538; Mon, 11 Jun 2001 21:46:21 +0100 Message-ID: <3B252C07.CD95@hursley.ibm.com> Date: Mon, 11 Jun 2001 15:37:27 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Iljitsch van Beijnum CC: multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On Mon, 11 Jun 2001, Brian E Carpenter wrote: > > > This is my problem with this proposal, as it has been with every geo addressing > > proposal over the last 5 years. > > > Because of this fact (you have to increase the area covered until it is > > big enough to be flat-routable), I think that every geo area would > > reproduce exactly the problem of entropy and default-route-table bloat > > that we have in today's tiny little Internet. > > When the number of routes per area grows, it is likely that the areas > themselves shrink, if only for this very reason. I'm not saying geographic > aggregation will magically make all the problems go away. However, it will > buy us two or three orders of magnitude, which is nothing to sneeze at. We are not communicating. You deleted the text that my initial "this" refers to, but I think the exact opposite is true: the areas will have to grow, since ISP interconnections are essentially random with respect to geography. Also the cost pressure is going to be against local exchanges and in favour of large regional exchanges. Given this (and other points noted below) I don't see that geo addressing buys us anything much at all, certainly not orders of magnitude. > > > So I have little confidence > > that this solution is scaleable to the 10 billion node Internet. > > The number of nodes is not very relevant: you can fit 10 billion many, many > times inside the /48 a single customer would get. All that matters is the > number or routes and the resources needed to transmit, process and store each > route. Ignoring household subnets, we can expect several orders of magnitude more business subscribers than today - that's the significance of the total size of the network. > In IPv4 aggregation isn't used to its full potential, for historical > and address depletion reasons (besides some ignorance) and because of > multihoming. In IPv6 it will be much simpler to agressively aggregate, > because there is little need to give ISPs only small blocks of address space > and have them come back for more as they grow. > > So the main threat to the routing table are the multihomed networks. Agreed. > ...It would > be nice to know how many people or business will be multihomed in the future, > but there are no real figures. We only know that the number is still > relatively small but rising fast. I think we can get away with assuming an > upper limit on multihoming of 1% of the population. This is something like > 10% of all businesses. The only safe design target is 100% of all businesses, i.e. several orders of magnitude bigger than today's Internet. I see nothing that would limit it to 10% or any other particular level; it is likely that multihoming just becomes the normal thing to do. > Obviously anything that does better than 1% would be > great, but if we can achieve 1% we'll have bought a lot of time to think > about the other 99%. Not if the solution is worse than the problem. I believe that geo addressing simply reproduces pre-CIDR IPv4, since it is based on unrealistic assumptions about inter-ISP connectivity. > > With a world population of 10 billion looming, this would be 100 million > routes to multihomed networks. This is too much for any single router. > However, if we can break up the world into 100 regions, this would only be 1 > (or rather 2) million per region, which is still a lot but managable, if not > now at least in the near future. It would, if such a scenario was plausible, which I don't believe. > > Combined with more efficient ways to store and transmit routes, this should > work for a long time to come. > > The current routing paradigm is to store a lot of information about each > individual route, since aggregation makes sure there aren't very many similar > routes. But in a few years (decades) when 1% of New York City is multihomed, > this means more than 200k routes (to 100k destinations) within a fairly small > geographic region. If this market is serviced by 20 ISPs this means 10,000 > routes per ISP, each taking more than 100 bytes of memory, even though these > routes are likely to be nearly identical. > > If we assign all these addresses out of a single 131072 * /48 block and then > each ISP uses a bitmap attached to the aggregated /31 to announce whether any > of those /48's is connected to them, it only takes somewhat over 100 bytes > for the /31 + a 16k bitmap for a total of ~16500 bytes in stead of more than > a megabyte. Another ISP that peers with all of them will only get some 330 > kilobyte of routing information in stead of 20 MB. Perhaps, but every time there is a change they will get it all again instead of just one item. There are multiple tradeoffs here. I'm all in favour of summarisation but that is not the only performance issue. > > My idea for geographical aggregation can be deployed in the current IPv4/BGP4 > Internet without breaking anything. The only thing that has to be done is > divvy up the world in regions and assign address space to multihomed networks > within the same region from an aggregatable block. Then networks can start to > filter out routes from blocks far away without the risk of suboptimal routing > to multihomed networks closer by if and when they want, with potential > benefits of new route storage paradigms in the future. Only if you revolutionise ISP interconnection strategies and find some way to change the underlying economics. Don't misunderstand me - we need a radical solution. I just don't think that geo addressing, which is fundamentally the telephone solution, is radical enough. Brian From owner-multi6@ops.ietf.org Mon Jun 11 19:45:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20793 for ; Mon, 11 Jun 2001 19:45:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159bMg-0009ab-00 for multi6-data@psg.com; Mon, 11 Jun 2001 16:44:58 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.16 #1) id 159bMf-0009aU-00 for multi6@ops.ietf.org; Mon, 11 Jun 2001 16:44:57 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 11 Jun 2001 16:44:47 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 7BB90342D2DA4F9AB6860500AE0C987F for plus 2 more; Mon, 11 Jun 2001 16:44:47 -0700 Reply-To: From: "Tony Hain" To: "Brian E Carpenter" , "Iljitsch van Beijnum" Cc: Subject: RE: Regionally aggregatable address space for multihoming Date: Mon, 11 Jun 2001 16:44:46 -0700 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3B252C07.CD95@hursley.ibm.com> Importance: Normal X-SLUIDL: 12BAA3B3-B4C7488C-B3D12F30-888F458D Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > Also the cost pressure is going to be against local exchanges > and in favour of large regional exchanges. Given this (and > other points noted below) I don't see that geo addressing buys us > anything much at all, certainly not orders of magnitude. Take the example of just an 8-bit prefix using my proposal. The globe divides into 128 regions, with 68 unusable (32 are polar, 36 are basically water). Of the remaining, I count 16 that map into current telecommunications centers. While some neighboring regions may find it advantageous to leak full routes between themselves, there should be at least 12 that end up summarized. Yes a region has flat routes, but it doesn't need more than 3/4 of the table, and will probably do better than that. The interconnection robustness at this scale is fairly high, so we could get some gain. Within the regions, it becomes a mater of local politics and business practice as to how much further the plan can go. Certainly it will be more difficult in either Europe or the US than all the others combined, but if you write off those 4 regions as hopelessly intertwined there is still an opportunity for significant gain in the rest of the world. > The only safe design target is 100% of all businesses With a geo plan you get 'all sites', and don't need to worry if it is a business or not. > Not if the solution is worse than the problem. I believe that > geo addressing simply reproduces pre-CIDR IPv4, since it is based > on unrealistic assumptions about inter-ISP connectivity. Only over a given scope. The CIDR roll out effort also showed what backpressure from the top could do to constrain entropy. It also showed what happens if you push too hard. When you try to over-engineer and enforce controls for maximum optimization you will loose control and be back where you started. This is where the rewriting the goop plan falls flat, because they are targeted at absolute optimization in the middle, without concern for systemic impact. > Only if you revolutionise ISP interconnection strategies and > find some way to change the underlying economics. Geoff Huston should be stepping up to this one. There is no need to change human nature, just provide a reasonable tool for aggregation then charge for carrying explicit routes when people insist on them. Match the economics to human nature rather than trying to invent a technological restraint system. > Don't misunderstand me - we need a radical solution. I just > don't think that geo addressing, which is fundamentally the > telephone solution, is radical enough. It may not be for the long run, but we need something to get IPv6 off the ground in the mind of ISPs. So far they are complaining that it offers nothing to solve the immediate scaling problem with provider based addressing; so the obvious step is to remove all reference to provider from the address. Other than cases of enforced portability, this is not the telephone model. There, as the address space was divvied up, the provider boundaries happened to align with a political notion of geography. A WGS-84 based plan is even devoid of political boundaries. Tony From owner-multi6@ops.ietf.org Tue Jun 12 05:38:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11219 for ; Tue, 12 Jun 2001 05:38:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159kdI-000Fi8-00 for multi6-data@psg.com; Tue, 12 Jun 2001 02:38:44 -0700 Received: from mako1.telstra.net ([203.50.0.28]) by psg.com with esmtp (Exim 3.16 #1) id 159kdH-000Fi2-00 for multi6@ops.ietf.org; Tue, 12 Jun 2001 02:38:43 -0700 Received: from tecra.telstra.net (gorp.telstra.net [203.50.0.66]) by mako1.telstra.net (8.11.3/8.11.1) with ESMTP id f5C9c8696700; Tue, 12 Jun 2001 19:38:14 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20010612161648.00c3e510@jumble.telstra.net> X-Sender: gih@jumble.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jun 2001 16:50:59 +1000 To: From: Geoff Huston Subject: RE: Regionally aggregatable address space for multihoming Cc: "Brian E Carpenter" , "Iljitsch van Beijnum" , In-Reply-To: References: <3B252C07.CD95@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk > > Only if you revolutionise ISP interconnection strategies and > > find some way to change the underlying economics. >Geoff Huston should be stepping up to this one. There is no need to change >human nature, just provide a reasonable tool for aggregation then charge for >carrying explicit routes when people insist on them. Match the economics to >human nature rather than trying to invent a technological restraint system. Ok - I'll step up to this. The theory is fine, but the practice is harder to identify. I find it hard to conceive as to what a 'geography' may be when its cheaper to cross the Atlantic by submarine cable, station to station, than it is to do last mile at either end. We had this model in our collective industry heads that "distance = cost" and that local geographies see some cost benefit in locally interconnecting. In the current communications environments the cost of local regulatory regimes appears to be greater than the cost of distance, and a least cost community of common benefit has no geographic counterpart. We are certainly on the horns of some form of dilemma - conventional routing wisdom indicates that some form of hierarchy is one of the few tools that address route scaleability - through hierarchies fine detail is obscured at a distance, and these details only become visible at a local level. However, the cost of circuitry is inexorably dropping - customers find it cost effective to drag two or more local circuits to two or more upstreams as the most cost effective response to resiliency requirements. Providers find it cost effective to drag long haul circuits all over the place as a means of bypassing various components of a locally-provided upstream transit service. At what point in the long haul over-supply market will the long haul providers start to look at end customers as a potential long-haul customers, and at what point will multi-homing become a non-local problem? What appears to be happening is that "geographic" locality and "least cost" locality don't match all that closely. (Yes this "long distance is cheaper" sounds far fetched, but its also far a far fetched, but current, reality which makes a Tokyo - LA circuit cheaper than a Tokyo - Osaka circuit.) So inside all this I see and understand that IF we had a pretty solid "distance = cost" dominant cost model then there would be a fair incentive for local interconnection - to some extent. If we _also_ had a different inter-provider settlement model where every packet was purchased from its originating provider and on-sold to its terminating provider (to borrow some PSTN settlement terms with a reselling margin equal to the marginal cost of transit), then there would be an even stronger case for local interconnection, and, furthermore if the packet accounting settlement rates were fixed according to some imposed industry model, then the case for regionally aggregateable addresses would be pretty solid. Needless to say, by this stage you are pretty close to the PSTN original interprovider settlement model and about 1,000,000 miles away from the Internet of today. There are a number of theoretically stable inter-provider economic models that could support an Internet. There are very few models which also allow a transition from today's reality to an end point of universal adoption of the particular model. I have this depressing view (*) that metro routing aggregation is one of these models which could work, but the path from here to there is not visible to me at any rate. (*) depressing to me at any rate, because most of the routing scaling tools infer the use of hierarchies, which in turn require a pretty substantial shift of current operating practice. There may be some other approaches: if you concede that a full routing table at some point in the future will have some considerable cost in terms of specialized support machinery, then the market will sort itself out through the use of different route filters applied to peers, customers and upstreams. The implied route scaling cost of multi-homing would become as explicit cost of protocol scaling, and there would be a solid economic incentive to single-home. But, that's a big concession, and one which has no basis in what we are seeing today. Today its the protocol which is showing signs of scaling stress, not the routing engines, and attempting to work out an economic model which applies local pressure for a greater common good of protocol stability is a tough ask. Geoff From owner-multi6@ops.ietf.org Tue Jun 12 06:55:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11597 for ; Tue, 12 Jun 2001 06:55:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159lo7-000GPa-00 for multi6-data@psg.com; Tue, 12 Jun 2001 03:53:59 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 159lo6-000GPT-00 for multi6@ops.ietf.org; Tue, 12 Jun 2001 03:53:58 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f5CAmGH76161; Tue, 12 Jun 2001 12:48:17 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 12 Jun 2001 12:43:50 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Geoff Huston cc: alh-ietf@tndh.net, Brian E Carpenter , multi6@ops.ietf.org Subject: RE: Regionally aggregatable address space for multihoming In-Reply-To: <4.3.2.7.2.20010612161648.00c3e510@jumble.telstra.net> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 12 Jun 2001, Geoff Huston wrote: > I find it hard to conceive as to what a 'geography' may be when its cheaper > to cross the Atlantic by submarine cable, station to station, than it is to > do last mile at either end. We had this model in our collective industry > heads that "distance = cost" and that local geographies see some cost > benefit in locally interconnecting. In the current communications > environments the cost of local regulatory regimes appears to be greater > than the cost of distance, and a least cost community of common benefit has > no geographic counterpart. I think you are painting too bleak a picture. Let me tell you a story. Five, six years ago the Internet business was in its infancy here in The Netherlands. We were connected to the net over British Telecom with a frame relay line to the UK over a leased line to Amsterdam. So if we wanted to connect to someone else in Holland, the first hop would be London and then the packets would take a tour of Europe over Geneva or Stockholm and back to The Netherlands (99% of the time Amsterdam). Or the traffic would flow over New York, Washington and/or New Jersey. The reason for this was simple: everybody needed a good connection to the US and the large networks wouldn't interconnect with the smaller ones at the local exchange. There wasn't enough European traffic to justify many links between European countries. (I did some counting back in those days and 45% of the traffic was to Dutch destionations, 45% to US destinations and only 10% to other European destinations.) Today the situation is completely different. Large networks such as UUNET/MCI/Worldcom have pan-european networks so in many cases traffic takes the shortest route to other European destinations. Transatlantic capacity is very cheap, but not as cheap as housing a router at the Amsterdam Internet Exchange and exchanging tens or hundreds of megabytes without any traffic charges. Some of the really large networks still don't want to interconnect with the smaller ones, but even the traffic between the small networks is enough to make it worth connecting. > We are certainly on the horns of some form of dilemma - conventional > routing wisdom indicates that some form of hierarchy is one of the few > tools that address route scaleability - through hierarchies fine detail is > obscured at a distance, and these details only become visible at a local > level. However, the cost of circuitry is inexorably dropping - customers > find it cost effective to drag two or more local circuits to two or more > upstreams as the most cost effective response to resiliency requirements. > Providers find it cost effective to drag long haul circuits all over the > place as a means of bypassing various components of a locally-provided > upstream transit service. At what point in the long haul over-supply market > will the long haul providers start to look at end customers as a potential > long-haul customers, and at what point will multi-homing become a non-local > problem? What appears to be happening is that "geographic" locality and > "least cost" locality don't match all that closely. (Yes this "long > distance is cheaper" sounds far fetched, but its also far a far fetched, > but current, reality which makes a Tokyo - LA circuit cheaper than a Tokyo > - Osaka circuit.) You have convinced me at least to the point where I have to admit that just assuming that interconnectivity will become more and more local in the future is a dangerous assumption. But rather than invalidate the argument for geographic aggregation you merely weaken it. Even if it's cheaper to connect to LA than to Osaka for someone in Tokyo, it's still cheaper to connect to LA than to New York or Johannesburg. To put it more generally: even if long distance is cheap, it still doesn't make sense to bypass one hub and connect to one further away. Also, there are other reasons why long distance isn't fun. First of all, there is the delay. Some applications just can't tolerate an extra 80 ms round trip time. Another problem is that if you get traffic for a very large region together at one point, it is much harder to handle. Today's routers can maybe do 10 Gbps. So if you have 1 Gbps worth of customers in a city, it doesn't make much sense to aggregate traffic for 25 cities. > There may be some other approaches: if you concede that a full routing > table at some point in the future will have some considerable cost in terms > of specialized support machinery, then the market will sort itself out > through the use of different route filters applied to peers, customers and > upstreams. Yes. Combined with the current practice this is a very bad thing: if I run defaultless and I start to filter out routes to multihomed networks, I can't reach them at all. If there is a regional aggregate at least there is a fighting chance. > The implied route scaling cost of multi-homing would become as > explicit cost of protocol scaling, and there would be a solid economic > incentive to single-home. Not really. The people paying for the bigger routers aren't the same ones that are deciding to multihome. But that doesn't mean we can't create such an incentive. If a scalable way to do multihoming costs the networks more money, they can charge their customers more for the service. Just as long as the people who make the costs are also the people sending the bills, unlike the current situation. From owner-multi6@ops.ietf.org Tue Jun 12 07:54:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12069 for ; Tue, 12 Jun 2001 07:54:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159mjs-000H1z-00 for multi6-data@psg.com; Tue, 12 Jun 2001 04:53:40 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 159mjr-000H1s-00 for multi6@ops.ietf.org; Tue, 12 Jun 2001 04:53:39 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f5CBraH76253; Tue, 12 Jun 2001 13:53:36 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 12 Jun 2001 13:49:06 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Brian E Carpenter cc: multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming In-Reply-To: <3B252C07.CD95@hursley.ibm.com> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 11 Jun 2001, Brian E Carpenter wrote: [Problem with geo addressing: regions are big] > > When the number of routes per area grows, it is likely that the areas > > themselves shrink, if only for this very reason. I'm not saying geographic > > aggregation will magically make all the problems go away. However, it will > > buy us two or three orders of magnitude, which is nothing to sneeze at. > We are not communicating. You deleted the text that my initial "this" > refers to, but I think the exact opposite is true: the areas will have to > grow, since ISP interconnections are essentially random with respect to > geography. I guess this is true for the really large networks. Maybe this is because they've lacked a good incentive to interconnect at more locations. Geographic aggregation could be the necessary incentive. They are already present in many locations and local fiber is cheap, so it could happen. On the other hand, it may not. > Also the cost pressure is going to be against local > exchanges and in favour of large regional exchanges. Given this (and > other points noted below) I don't see that geo addressing buys us > anything much at all, certainly not orders of magnitude. I'm inclined to believe that there will be more local interconnection, but of course everything has to work regardless of what we believe. Do you agree that it would buy as at least one order of magnitude? That means three regional exchanges for North America and Europe and one for every other continent. > The only safe design target is 100% of all businesses, i.e. several orders of > magnitude bigger than today's Internet. I see nothing that would limit it > to 10% or any other particular level; it is likely that multihoming just becomes > the normal thing to do. 100% would be something like a billion. I think there is a natural limit because connecting to two ISPs is twice as expensive as connecting to one. A billion routes means we absolutely have to aggregate on something, probably on more than one thing at a time. > Don't misunderstand me - we need a radical solution. I just don't think that > geo addressing, which is fundamentally the telephone solution, is radical > enough. Hey, I'm just as radical as the next guy. But if we can't come up with a way to make a billion routes work before there are a million, the routers will choke and we don't have an internet anymore. I think I'll write up a draft on introducing geographic information into the current routing architecture. In BGP this could be a community, in IPv6 it could also be the top 8 bits in an end user /48. Then every user can decide for herself to implement it or not. Maybe it would help to make it possible to aggregate on other things than just the beginning of the address. IPv6 addresses are large enough to hold lots of good stuff we can potentially aggregate on. For instance, we could use two 16 bit field that hold the AS number of the two ISPs for a multihomed network. Then an ISP would simply announce aggregates like: 4567:ISP:: mask ffff:ffff:: 4567:0:ISP:: mask ffff:0:ffff:: With every kind of aggregation there is the problem of holes. If the customer is disconnected from ISP 1 and ISP 1 still announces the aggregate, ISP 1 has to know it has to forward the traffic to ISP 2 at some point. With just two ISPs this can be done without exchanging any more specifics by just dumping the traffic at the other network if there is no local (= this network) more specific route to the customer. Iljitsch From owner-multi6@ops.ietf.org Tue Jun 12 10:29:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16338 for ; Tue, 12 Jun 2001 10:29:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159pAY-000Iqd-00 for multi6-data@psg.com; Tue, 12 Jun 2001 07:29:22 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 159pAY-000IqX-00 for multi6@ops.ietf.org; Tue, 12 Jun 2001 07:29:22 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 159pAX-0005TJ-00 for multi6@ops.ietf.org; Tue, 12 Jun 2001 07:29:21 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" From: RJ Atkinson To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: RE: Regionally aggregatable address space for multihoming In-Reply-To: References: <4.3.2.7.2.20010612161648.00c3e510@jumble.telstra.net> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 12 Jun 2001 07:29:22 -0700 At 06:43 12/06/01, Iljitsch van Beijnum wrote: >Today the situation is completely different. Large networks such as >UUNET/MCI/Worldcom have pan-european networks so in many cases >traffic takes the shortest route to other European destinations. >Transatlantic capacity is very cheap, but not as cheap as housing >a router at the Amsterdam Internet Exchange and exchanging tens >or hundreds of megabytes without any traffic charges. Some of the >really large networks still don't want to interconnect with the >smaller ones, but even the traffic between the small networks >is enough to make it worth connecting. It is still the case that metro circuits within most major European cities are most often *more* expensive than equally sized circuits that run between countries. Further, Amsterdam, London, and Stockholm are exceptions in that each is both a major European city and each has a plausibly health IP exchange point. There are a much larger number of major European cities. Most have no exchange point at all. Some have a very small one that isn't really viable at present. However, let me suggest that giving and disagreeing about examples aren't really the focus here, because the world is a much larger place than the EU (or the US or AU for that matter :-). We need a routing/operational/business model that supports multi-homing globally, not just regionally, and that supports widespread multi-homing of end users in a manner that does not adversely impact the health of the global routing system. The mere fact that in many places (not all, just many) local-loop charges are higher than long-distance charges means that the model we need must be economically sensible when the long-distance is less expensive than the local loop. Regards, Ran rja@inet.org From owner-multi6@ops.ietf.org Tue Jun 12 10:31:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16410 for ; Tue, 12 Jun 2001 10:31:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159pCN-000IsJ-00 for multi6-data@psg.com; Tue, 12 Jun 2001 07:31:15 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 159pCM-000IsD-00 for multi6@ops.ietf.org; Tue, 12 Jun 2001 07:31:14 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 159pCM-0005Wo-00 for multi6@ops.ietf.org; Tue, 12 Jun 2001 07:31:14 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" From: RJ Atkinson To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming In-Reply-To: References: <3B252C07.CD95@hursley.ibm.com> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 12 Jun 2001 07:31:15 -0700 At 07:49 12/06/01, Iljitsch van Beijnum wrote: >I guess this is true for the really large networks. Maybe this is >because they've lacked a good incentive to interconnect at more >locations. Geographic aggregation could be the necessary incentive. >They are already present in many locations and local fiber is cheap, >so it could happen. On the other hand, it may not. Local fibre is cheap in some places, expensive in others. In some places, long-haul connectivity is much less expensive than local connectivity. In other places, the inverse is probably true. When designing a global system, few generalisations can be accurate. If we boil the above down, ISPs are incented to connect over low-cost links, with regards to the distance of the link. At the end, economics will dominate those business decisions. Given that, I don't see how trying to force a local exchange system will be effective anytime soon. And I don't necessarily think that forcing such will actually provide significant improvement. I'm open minded about the latter, but would need to see more substantial explanation of how such actually improves the health of the global routing system (something notionally similar to a paper in ACM CCR describing the reasons for improvement in global routing system health would be a nice start :-). Cheers, Ran From owner-multi6@ops.ietf.org Tue Jun 12 10:48:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16883 for ; Tue, 12 Jun 2001 10:47:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159pRZ-000J7u-00 for multi6-data@psg.com; Tue, 12 Jun 2001 07:46:57 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 159pRY-000J7m-00 for multi6@ops.ietf.org; Tue, 12 Jun 2001 07:46:56 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f5CEjYH76430; Tue, 12 Jun 2001 16:45:34 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 12 Jun 2001 16:40:55 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: RJ Atkinson cc: multi6@ops.ietf.org Subject: RE: Regionally aggregatable address space for multihoming In-Reply-To: <5.1.0.14.2.20010612100549.00a22780@10.30.15.2> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 12 Jun 2001, RJ Atkinson wrote: > However, let me suggest that giving and disagreeing > about examples aren't really the focus here, because the world > is a much larger place than the EU (or the US or AU for that > matter :-). The point of the story is that a lot can change in five years. > The mere fact that in many places (not all, just many) > local-loop charges are higher than long-distance charges means > that the model we need must be economically sensible when the > long-distance is less expensive than the local loop. Long distance and local loop are really apples and oranges. From my living room to New York is much, much more expensive than from my living room to the other side of the city. However, from the Worldcom colocation building to New York is probably cheaper than to the other side of the city. But from the Worldcom colocation building to the Level3 colocation building is probably a lot cheaper than from either to New York, and certainly than from Worldcom to New York and then back to Level3. And even if a connection over New York is cheaper, it is still possible to exchange layer 3 local traffic over layer 1/2 long distance connections if this keeps the routing table from exploding. Iljitsch From owner-multi6@ops.ietf.org Tue Jun 12 11:18:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17527 for ; Tue, 12 Jun 2001 11:18:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159pvz-000Jbx-00 for multi6-data@psg.com; Tue, 12 Jun 2001 08:18:23 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 159pvy-000Jbq-00 for multi6@ops.ietf.org; Tue, 12 Jun 2001 08:18:22 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f5CFH5H76482; Tue, 12 Jun 2001 17:17:05 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 12 Jun 2001 17:12:23 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: RJ Atkinson cc: multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming In-Reply-To: <5.1.0.14.2.20010612101548.00a23a70@10.30.15.2> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 12 Jun 2001, RJ Atkinson wrote: > At 07:49 12/06/01, Iljitsch van Beijnum wrote: > >I guess this is true for the really large networks. Maybe this is > >because they've lacked a good incentive to interconnect at more > >locations. Geographic aggregation could be the necessary incentive. > >They are already present in many locations and local fiber is cheap, > >so it could happen. On the other hand, it may not. > Local fibre is cheap in some places, expensive in others. You are right, it can be expensive. I was thinking along the line of hardware and investments. Obviously, for non-telco ISPs the market price is more relevant. > Given that, I don't see how trying to force a local > exchange system will be effective anytime soon. Does anyone have a good overview of the current world wide situation? As far as I can tell routing is pretty good these days, I hardly ever see packets taking the scenic route halfway around Europe or the US these days. Of course I see mostly traffic that has NL as the source or destination, so this doesn't mean all that much. > And I don't > necessarily think that forcing such will actually provide > significant improvement. I'm open minded about the latter, > but would need to see more substantial explanation of how > such actually improves the health of the global routing > system Well, let's reverse the argument: how will assigning very small blocks of address space to multihomed networks with no particular rationale help us? At least with a geographic assignment policy some people can filter some announcements in some parts of their network some of the time. As I see it, my original proposal (or the proposal by Tony Hain) aren't going to fix all routing issues forever, because we have to plan for too many multihomed networks (a billion) and we cannot depend on enough local interconnectivity between ISPs. On the other hand, it should help a bit and it won't break anything. So we have to think of something better. I still think geography can be a good "better than nothing" attribute when there is no better information available, but we'll see. Iljitsch From owner-multi6@ops.ietf.org Thu Jun 14 17:07:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09792 for ; Thu, 14 Jun 2001 17:07:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15AeJG-000CxM-00 for multi6-data@psg.com; Thu, 14 Jun 2001 14:05:46 -0700 Received: from flowpoint.procket.com ([209.140.237.1] helo=alpha-tli.procket.com) by psg.com with esmtp (Exim 3.16 #1) id 15AeJF-000CxD-00 for multi6@ops.ietf.org; Thu, 14 Jun 2001 14:05:45 -0700 Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id OAA29136; Thu, 14 Jun 2001 14:04:36 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15145.9955.182872.840953@alpha-tli.procket.com> Date: Thu, 14 Jun 2001 14:04:35 -0700 (PDT) To: Brian E Carpenter Cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming In-Reply-To: <3B252C07.CD95@hursley.ibm.com> References: <3B252C07.CD95@hursley.ibm.com> X-Mailer: VM 6.75 under Emacs 20.5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | Don't misunderstand me - we need a radical solution. I just don't think that | geo addressing, which is fundamentally the telephone solution, is radical | enough. Here's a radical idea: How about we stop trying to repeat the decade-old debate about routing architectures and focus on getting multihoming into IPv6? We decided a long time ago, for better or for worse, that we were not going to introduce a new routing architecture with IPv6. We need a multihoming solution that at the very least halts the global routing table explosion. If we can't find one, then we have a bigger problem to be sure, but let's focus on trying to converge on something. Tony From owner-multi6@ops.ietf.org Thu Jun 14 18:09:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10632 for ; Thu, 14 Jun 2001 18:09:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15AfI5-000DxS-00 for multi6-data@psg.com; Thu, 14 Jun 2001 15:08:37 -0700 Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by psg.com with esmtp (Exim 3.16 #1) id 15AfI4-000Dwe-00 for multi6@ops.ietf.org; Thu, 14 Jun 2001 15:08:36 -0700 Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA42098 for ; Thu, 14 Jun 2001 15:08:03 -0700 Received: from hursley.ibm.com (lig32-227-96-124.us.lig-dial.ibm.com [32.227.96.124]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA11412 for ; Thu, 14 Jun 2001 15:07:58 -0700 Message-ID: <3B293372.EE9935B4@hursley.ibm.com> Date: Thu, 14 Jun 2001 16:58:11 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Multi6 Subject: Requirements Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Multi6 Chairs, Can we work on getting the requirements locked and loaded ASAP? I apologise for having given in to the temptation of discussing a proposed solution prematurely. Brian From owner-multi6@ops.ietf.org Fri Jun 15 07:50:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04013 for ; Fri, 15 Jun 2001 07:50:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15As4x-000OD2-00 for multi6-data@psg.com; Fri, 15 Jun 2001 04:47:55 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 15As4w-000OCw-00 for multi6@ops.ietf.org; Fri, 15 Jun 2001 04:47:54 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f5FBlkH81104; Fri, 15 Jun 2001 13:47:47 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 15 Jun 2001 13:47:43 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Tony Li cc: Brian E Carpenter , multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming In-Reply-To: <15145.9955.182872.840953@alpha-tli.procket.com> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 14 Jun 2001, Tony Li wrote: > We decided a long time ago, for better or for worse, that we were not going > to introduce a new routing architecture with IPv6. We need a multihoming > solution that at the very least halts the global routing table explosion. > If we can't find one, then we have a bigger problem to be sure, but let's > focus on trying to converge on something. Let's see if we can agree on the problem: The large number of multihomed network is responsible for growth of the routing table, which we don't want because: - it takes too much CPU power to process routing updates - it takes too much memory to store the table - it takes too much CPU power to look up routes when forwarding packets Is stopping the routing table growth the best way to address these problems? If so, the next step is to choose an approach, such as: - not allowing or restricting multihoming the way it is done now This means we need alternatives, such as a good way to select the best address when a host has more than one and ways for higher layers to survive address changes. - find a way to aggregate multihomed routes On what should we aggregate? Topology, geography? - ??? I think the discussion so far shows that each approach has serious drawbacks, but just waiting until the perfect solution comes along doesn't seem to work either. So we need a way to select a best approach in lieu of a perfect one. What do we value more? Effectiveness? Efficient operation? Simplicity? Compatibility with current practices? How can we evaluate all of this if we don't make assumptions about the future of the Internet? From owner-multi6@ops.ietf.org Fri Jun 15 13:35:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18576 for ; Fri, 15 Jun 2001 13:35:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15AxV4-000B4s-00 for multi6-data@psg.com; Fri, 15 Jun 2001 10:35:14 -0700 Received: from d61.wireless.hilander.com ([216.241.32.61] helo=ramirez.hilander.com) by psg.com with esmtp (Exim 3.16 #1) id 15AxV1-000B4l-00 for multi6@ops.ietf.org; Fri, 15 Jun 2001 10:35:11 -0700 Received: from [216.241.32.50] (helo=gathering) by ramirez.hilander.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.22 #2) id 15AxUR-00041u-00; Fri, 15 Jun 2001 11:34:35 -0600 Message-ID: <036301c0f5c1$71cf05e0$3220f1d8@windows.hilander.com> From: "Alec H. Peterson" To: "Iljitsch van Beijnum" , "Tony Li" Cc: "Brian E Carpenter" , References: Subject: Re: Regionally aggregatable address space for multihoming Date: Fri, 15 Jun 2001 11:34:31 -0600 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Iljitsch van Beijnum" To: "Tony Li" Cc: "Brian E Carpenter" ; Sent: Friday, June 15, 2001 05:47 Subject: Re: Regionally aggregatable address space for multihoming > > Is stopping the routing table growth the best way to address these > problems? If so, the next step is to choose an approach, such as: > > - not allowing or restricting multihoming the way it is done now > This means we need alternatives, such as a good way to select the best > address when a host has more than one and ways for higher layers > to survive address changes. Well, multi-homing nowadays doesn't necessarily involve selecting the 'best' route, it just selects a valid route (the lack of any QoS makes trying to select the best route on a wide-area scale futile IMO). So, until inter-domain QoS becomes a reality, making finding the best route (or in this case, the best address) a requirement probably won't help. With this in mind, I think we can more easily come up with a valid multiple address solution by simply stating that the network needs to find 'a' route between the two end-points. Alec From owner-multi6@ops.ietf.org Fri Jun 15 19:44:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01743 for ; Fri, 15 Jun 2001 19:44:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15B3Fs-0000qw-00 for multi6-data@psg.com; Fri, 15 Jun 2001 16:43:56 -0700 Received: from flowpoint.procket.com ([209.140.237.1] helo=alpha-tli.procket.com) by psg.com with esmtp (Exim 3.16 #1) id 15B3Fr-0000oR-00 for multi6@ops.ietf.org; Fri, 15 Jun 2001 16:43:55 -0700 Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id OAA30870; Fri, 15 Jun 2001 14:44:46 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15146.33230.95107.164639@alpha-tli.procket.com> Date: Fri, 15 Jun 2001 14:44:46 -0700 (PDT) To: Iljitsch van Beijnum Cc: Tony Li , Brian E Carpenter , multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming In-Reply-To: References: <15145.9955.182872.840953@alpha-tli.procket.com> X-Mailer: VM 6.75 under Emacs 20.5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | Let's see if we can agree on the problem: | | The large number of multihomed network is responsible for growth of the | routing table, which we don't want because: | | - it takes too much CPU power to process routing updates | - it takes too much memory to store the table | - it takes too much CPU power to look up routes when forwarding packets | | Is stopping the routing table growth the best way to address these | problems? Some fine points: - We will never actually 'stop' routing table growth. It will continue. The question is the rate. - We would very much like to keep that rate below Moore's law. It will become exceedingly painful if and when it exceeds Moore's law. The hardware will simply fail to keep up. | If so, the next step is to choose an approach, such as: | | - not allowing or restricting multihoming the way it is done now | This means we need alternatives, such as a good way to select the best | address when a host has more than one and ways for higher layers | to survive address changes. | | - find a way to aggregate multihomed routes | On what should we aggregate? Topology, geography? | | - ??? We already have a unicast routing architecture for V6 that dictates how aggregation is to be performed. The goal of this WG is to decide on a strategy for how do deal with multihomed sites in some way other than what we do today (global visibility of all multihomed sites without any aggregation). There are two proposals on the table: - GSE - multiple addresses The goal of this WG is to decide on one, without bloodshed, in less than an epoch. So far, things aren't looking good. | I think the discussion so far shows that each approach has serious | drawbacks, but just waiting until the perfect solution comes along | doesn't seem to work either. So we need a way to select a best approach | in lieu of a perfect one. What do we value more? Effectiveness? | Efficient operation? Simplicity? Compatibility with current practices? | How can we evaluate all of this if we don't make assumptions about the | future of the Internet? This is supposed to all be captured in the (alleged) requirements document. Tony From owner-multi6@ops.ietf.org Mon Jun 18 16:09:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19764 for ; Mon, 18 Jun 2001 16:09:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15C5JC-0004fu-00 for multi6-data@psg.com; Mon, 18 Jun 2001 13:07:38 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.16 #1) id 15C5JA-0004fg-00 for multi6@ops.ietf.org; Mon, 18 Jun 2001 13:07:36 -0700 Received: (qmail 20667 invoked by uid 100); 18 Jun 2001 20:07:27 -0000 Date: Mon, 18 Jun 2001 16:07:26 -0400 From: Joe Abley To: Sean Doran Cc: alh-ietf@tndh.net, multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming Message-ID: <20010618160726.J5787@buddha.home.automagic.org> References: <5266e7auyh.fsf@sean.ebone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5266e7auyh.fsf@sean.ebone.net>; from smd@ebone.net on Fri, Jun 08, 2001 at 04:48:38PM +0200 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jun 08, 2001 at 04:48:38PM +0200, Sean Doran wrote: > "Tony Hain" writes: > > Tony, thanks for the first rev of a draft! I have some > comments and questions that I hope may help improve it. > > > sites that connect to metropolitan scale exchanges. > > Do such exchanges exist? I'm curious, since I haven't run into any, > even in Stockholm, where fibre is very close to free. Sorry about the late comment, but there's one in Wellington, New Zealand, which has been in operation for some time. It is run by Citylink (see http://www.citylink.co.nz/). For what that's worth :) Joe From owner-multi6@ops.ietf.org Mon Jun 18 17:35:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21766 for ; Mon, 18 Jun 2001 17:35:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15C6gW-0006iE-00 for multi6-data@psg.com; Mon, 18 Jun 2001 14:35:48 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.16 #1) id 15C6gV-0006i7-00 for multi6@ops.ietf.org; Mon, 18 Jun 2001 14:35:47 -0700 Received: (qmail 10059 invoked by uid 100); 18 Jun 2001 21:35:45 -0000 Date: Mon, 18 Jun 2001 17:35:45 -0400 From: Joe Abley To: Iljitsch van Beijnum Cc: Tony Li , Brian E Carpenter , multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming Message-ID: <20010618173545.S5787@buddha.home.automagic.org> References: <15145.9955.182872.840953@alpha-tli.procket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from iljitsch@muada.com on Fri, Jun 15, 2001 at 01:47:43PM +0200 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jun 15, 2001 at 01:47:43PM +0200, Iljitsch van Beijnum wrote: > On Thu, 14 Jun 2001, Tony Li wrote: > > > We decided a long time ago, for better or for worse, that we were not going > > to introduce a new routing architecture with IPv6. We need a multihoming > > solution that at the very least halts the global routing table explosion. > > If we can't find one, then we have a bigger problem to be sure, but let's > > focus on trying to converge on something. > > Let's see if we can agree on the problem: > > The large number of multihomed network is responsible for growth of the > routing table, which we don't want because: Is it just multi-homing that is at the source of the issue? What about the prefix-based inter-AS traffic engineering that Geoff alluded to in Minneapolis? What I mean is: suppose the multi-homing problem could be solved such that the the pervasiveness of multi-homing had no impact on the amount of state held in the DFZ. Would there still be a state problem to solve? To what extent can we deduce the problems that edge sites are trying to solve? The analysis I have seen to date tries to make deductions from snapshots of the state in the DFZ, as viewed from various different angles. It occurs to me that there is a limited toolbox available for edge sites to accomplish a number of things. Being able to hear someone hammering in the distance doesn't tell you what they are trying to build :) Joe From owner-multi6@ops.ietf.org Mon Jun 18 17:42:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21867 for ; Mon, 18 Jun 2001 17:42:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15C6kf-0006pH-00 for multi6-data@psg.com; Mon, 18 Jun 2001 14:40:05 -0700 Received: from flowpoint.procket.com ([209.140.237.1] helo=alpha-tli.procket.com) by psg.com with esmtp (Exim 3.16 #1) id 15C6kd-0006ov-00 for multi6@ops.ietf.org; Mon, 18 Jun 2001 14:40:04 -0700 Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id OAA07009; Mon, 18 Jun 2001 14:39:18 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15150.29958.381503.315743@alpha-tli.procket.com> Date: Mon, 18 Jun 2001 14:39:18 -0700 (PDT) To: Joe Abley Cc: Iljitsch van Beijnum , Tony Li , Brian E Carpenter , multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming In-Reply-To: <20010618173545.S5787@buddha.home.automagic.org> References: <15145.9955.182872.840953@alpha-tli.procket.com> <20010618173545.S5787@buddha.home.automagic.org> X-Mailer: VM 6.75 under Emacs 20.5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | > The large number of multihomed network is responsible for growth of the | > routing table, which we don't want because: | | Is it just multi-homing that is at the source of the issue? What | about the prefix-based inter-AS traffic engineering that Geoff | alluded to in Minneapolis? That is certainly a problem that needs to get solved. However, that is far outside the charter of this WG. Tony From owner-multi6@ops.ietf.org Mon Jun 18 17:53:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22072 for ; Mon, 18 Jun 2001 17:52:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15C6x3-0007Al-00 for multi6-data@psg.com; Mon, 18 Jun 2001 14:52:53 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15C6x2-0007Af-00 for multi6@ops.ietf.org; Mon, 18 Jun 2001 14:52:52 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15C6wq-0001XH-00; Mon, 18 Jun 2001 14:52:40 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Abley Cc: Iljitsch van Beijnum , Tony Li , Brian E Carpenter , multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming References: <15145.9955.182872.840953@alpha-tli.procket.com> <20010618173545.S5787@buddha.home.automagic.org> Message-Id: Date: Mon, 18 Jun 2001 14:52:40 -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Is it just multi-homing that is at the source of the issue? What > about the prefix-based inter-AS traffic engineering that Geoff > alluded to in Minneapolis? that is the ptomaine effort, yes? randy From owner-multi6@ops.ietf.org Mon Jun 18 17:55:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22097 for ; Mon, 18 Jun 2001 17:55:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15C6z8-0007CL-00 for multi6-data@psg.com; Mon, 18 Jun 2001 14:55:02 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.16 #1) id 15C6z7-0007C7-00 for multi6@ops.ietf.org; Mon, 18 Jun 2001 14:55:01 -0700 Received: (qmail 24468 invoked by uid 100); 18 Jun 2001 21:54:54 -0000 Date: Mon, 18 Jun 2001 17:54:54 -0400 From: Joe Abley To: Randy Bush Cc: Iljitsch van Beijnum , Tony Li , Brian E Carpenter , multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming Message-ID: <20010618175454.T5787@buddha.home.automagic.org> References: <15145.9955.182872.840953@alpha-tli.procket.com> <20010618173545.S5787@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from randy@psg.com on Mon, Jun 18, 2001 at 02:52:40PM -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, Jun 18, 2001 at 02:52:40PM -0700, Randy Bush wrote: > > Is it just multi-homing that is at the source of the issue? What > > about the prefix-based inter-AS traffic engineering that Geoff > > alluded to in Minneapolis? > > that is the ptomaine effort, yes? It is. Sorry about the noise; I have too many lists being filtered into a single folder, and I had become confused over which list this thread belonged to. Joe From owner-multi6@ops.ietf.org Tue Jun 19 13:50:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28693 for ; Tue, 19 Jun 2001 13:50:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CPc0-000O49-00 for multi6-data@psg.com; Tue, 19 Jun 2001 10:48:24 -0700 Received: from cichlid.adsl.duke.edu ([152.16.64.203] helo=hygro.adsl.duke.edu ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15CPbz-000O3z-00 for multi6@ops.ietf.org; Tue, 19 Jun 2001 10:48:23 -0700 Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f5JHki303419; Tue, 19 Jun 2001 13:46:44 -0400 Message-Id: <200106191746.f5JHki303419@hygro.adsl.duke.edu> To: Brian E Carpenter cc: Multi6 Subject: Re: Requirements In-Reply-To: Message from Brian E Carpenter of "Thu, 14 Jun 2001 16:58:11 CDT." <3B293372.EE9935B4@hursley.ibm.com> Date: Tue, 19 Jun 2001 13:46:44 -0400 From: Thomas Narten Sender: owner-multi6@ops.ietf.org Precedence: bulk > Can we work on getting the requirements locked and loaded ASAP? Agreed. We need to nail this down. A revised version of draft-ietf-multi6-multihoming-requirements-00.txt is said to be coming shortly. Thomas From owner-multi6@ops.ietf.org Tue Jun 19 18:27:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06649 for ; Tue, 19 Jun 2001 18:27:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CTdz-0002Vf-00 for multi6-data@psg.com; Tue, 19 Jun 2001 15:06:43 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CTdy-0002VZ-00 for multi6@ops.ietf.org; Tue, 19 Jun 2001 15:06:42 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 19 Jun 2001 15:06:41 -0700 Message-ID: <006201c0f90c$1ead6de0$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: References: <15145.9955.182872.840953@alpha-tli.procket.com> <15146.33230.95107.164639@alpha-tli.procket.com> Subject: Re: Regionally aggregatable address space for multihoming Date: Tue, 19 Jun 2001 15:06:41 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 19 Jun 2001 22:06:41.0543 (UTC) FILETIME=[1EA50970:01C0F90C] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > There are two proposals on the table: > > - GSE > - multiple addresses > I no longer have a copy of the original GSE proposal. Does anybody have a good pointer to it? PF From owner-multi6@ops.ietf.org Tue Jun 19 20:07:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08399 for ; Tue, 19 Jun 2001 20:07:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CVWr-00064c-00 for multi6-data@psg.com; Tue, 19 Jun 2001 17:07:29 -0700 Received: from red.juniper.net ([207.17.136.137]) by psg.com with esmtp (Exim 3.16 #1) id 15CVWq-00063e-00 for multi6@ops.ietf.org; Tue, 19 Jun 2001 17:07:28 -0700 Received: from juniper.net (oreo.juniper.net [172.17.12.82]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id RAA01524; Tue, 19 Jun 2001 17:06:57 -0700 (PDT) Message-Id: <200106200006.RAA01524@red.juniper.net> To: "Paul Francis" cc: multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming In-reply-to: Your message of "Tue, 19 Jun 2001 15:06:41 PDT." <006201c0f90c$1ead6de0$50030a0a@tahoenetworks.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Tue, 19 Jun 2001 17:06:57 -0700 From: Andy Heffernan Sender: owner-multi6@ops.ietf.org Precedence: bulk > > > > There are two proposals on the table: > > > > - GSE > > - multiple addresses > > > > I no longer have a copy of the original GSE proposal. Does anybody have a > good pointer to it? ftp://ftp.uu.net/pub/mo/draft-ipng-gseaddr-00.txt ftp://ftp.uu.net/pub/mo/draft-ipng-gseaddr-00.ps From owner-multi6@ops.ietf.org Wed Jun 20 03:45:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00225 for ; Wed, 20 Jun 2001 03:45:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cce9-000MEl-00 for multi6-data@psg.com; Wed, 20 Jun 2001 00:43:29 -0700 Received: from mako1.telstra.net ([203.50.0.28]) by psg.com with esmtp (Exim 3.16 #1) id 15Cce8-000MEV-00; Wed, 20 Jun 2001 00:43:29 -0700 Received: from tecra.telstra.net (gorp.telstra.net [203.50.0.66]) by mako1.telstra.net (8.11.3/8.11.1) with ESMTP id f5K7hJB07721; Wed, 20 Jun 2001 17:43:20 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20010620100559.00c3e400@kahuna.telstra.net> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Jun 2001 10:08:34 +1000 To: Randy Bush From: Geoff Huston Subject: Re: Regionally aggregatable address space for multihoming Cc: Joe Abley , Iljitsch van Beijnum , Tony Li , Brian E Carpenter , multi6@ops.ietf.org In-Reply-To: References: <15145.9955.182872.840953@alpha-tli.procket.com> <20010618173545.S5787@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 6/19/01 07:52 AM, Randy Bush wrote: > > Is it just multi-homing that is at the source of the issue? What > > about the prefix-based inter-AS traffic engineering that Geoff > > alluded to in Minneapolis? > >that is the ptomaine effort, yes? no - the ptomaine effort attempts to say that lets continue to use the inter-domain routing protocol as connectivity + policy + TE and lets work how to identify the 'noise' associated with policy + TE and limit its promulgation with the routing fabric to some loosely defined boundary. This strikes me as a stop gap rather than an enduring scaleable solution, in my humble opinion. I dont mean to devalue ptomaine as I think that buying time is good if you have a problem, but my cautionary note is along the lines of not mistaking the band aid for the cure. :-) Geoff From owner-multi6@ops.ietf.org Wed Jun 20 03:45:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00227 for ; Wed, 20 Jun 2001 03:45:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CceU-000MF9-00 for multi6-data@psg.com; Wed, 20 Jun 2001 00:43:50 -0700 Received: from mako1.telstra.net ([203.50.0.28]) by psg.com with esmtp (Exim 3.16 #1) id 15CceT-000MF1-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 00:43:49 -0700 Received: from tecra.telstra.net (gorp.telstra.net [203.50.0.66]) by mako1.telstra.net (8.11.3/8.11.1) with ESMTP id f5K7hDB07713; Wed, 20 Jun 2001 17:43:14 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20010620093712.00bb66f0@kahuna.telstra.net> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Jun 2001 10:05:41 +1000 To: Joe Abley From: Geoff Huston Subject: Re: Regionally aggregatable address space for multihoming Cc: Iljitsch van Beijnum , Tony Li , Brian E Carpenter , multi6@ops.ietf.org In-Reply-To: <20010618173545.S5787@buddha.home.automagic.org> References: <15145.9955.182872.840953@alpha-tli.procket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 6/19/01 07:35 AM, Joe Abley wrote: > > Let's see if we can agree on the problem: > > > > The large number of multihomed network is responsible for growth of the > > routing table, which we don't want because: > >Is it just multi-homing that is at the source of the issue? What >about the prefix-based inter-AS traffic engineering that Geoff >alluded to in Minneapolis? Obviously the two are associated in some way. Once you have multiple connections the next motivation is to increase your efficiency - having one circuit packed to the brim with data and the other idle is not very efficient - if there is minimal incremental additional cost involved, the next step is to attempt to balance your normal inflow and outflow across the multiple circuits. Because there is no direct cost associated with advertising prefixes into the global routing table, and because advertising fine-grained prefixes selectively down particular paths achieves the objective of incoming traffic engineering, folk do it. >What I mean is: suppose the multi-homing problem could be solved >such that the the pervasiveness of multi-homing had no impact on >the amount of state held in the DFZ. Would there still be a state >problem to solve? The problem of traffic engineering is quite a challenging one: what you are attempting to do is to force remote systems to make a particular choice as to what paths are used to reach _you_ - its the reverse of the normal TE process. Now how do you communication that information to the remote system in a way that manages to constrain the choices available to the remote system to match your desired policy? Somehow theres an information transfer that has to happen. If its not the routing system then another information passing architecture is needed in addition to routing. i.e. you cannot 'solve' this problem by attempting to finesse thelast mile in a regional space - there remains a larger issue that must also be addressed. >To what extent can we deduce the problems that edge sites are >trying to solve? > >The analysis I have seen to date tries to make deductions from >snapshots of the state in the DFZ, as viewed from various >different angles. It occurs to me that there is a limited toolbox >available for edge sites to accomplish a number of things. Being >able to hear someone hammering in the distance doesn't tell you >what they are trying to build :) The bgp architecture draft I wrote and the March IETF plenary presentation attempted to highlight this. There is the constant sound of hammering and the BGP tables reflect this. If you want the routing system to deal in only AS-based connectivity then you can limit the stress in the routing tables BUT you also have to work out how to overlay policy / TE onto of this connectivity fabric, and thats the bit which I believe is the tricky one. Geoff From owner-multi6@ops.ietf.org Wed Jun 20 06:49:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01676 for ; Wed, 20 Jun 2001 06:49:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CfWY-0006ZB-00 for multi6-data@psg.com; Wed, 20 Jun 2001 03:47:50 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15CfWY-0006Z4-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 03:47:50 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15CfWU-000LCC-00; Wed, 20 Jun 2001 03:47:46 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Geoff Huston Cc: multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming References: <15145.9955.182872.840953@alpha-tli.procket.com> <20010618173545.S5787@buddha.home.automagic.org> <4.3.2.7.2.20010620100559.00c3e400@kahuna.telstra.net> Message-Id: Date: Wed, 20 Jun 2001 03:47:46 -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> Is it just multi-homing that is at the source of the issue? What >>> about the prefix-based inter-AS traffic engineering that Geoff >>> alluded to in Minneapolis? >> >> that is the ptomaine effort, yes? > > no - the ptomaine effort attempts to say that lets continue to use the > inter-domain routing protocol as connectivity + policy + TE and lets work > how to identify the 'noise' associated with policy + TE and limit its > promulgation with the routing fabric to some loosely defined boundary. > > This strikes me as a stop gap rather than an enduring scaleable solution, > in my humble opinion. I dont mean to devalue ptomaine as I think that > buying time is good if you have a problem, but my cautionary note is along > the lines of not mistaking the band aid for the cure. :-) i think we're actually in agreement on what is in multi6 and what in ptomaine, and that promaine is an attempt to stall until there is a cure. and this was fairly clearly set out in ptomain's original statements. i suspect where we may disagree is the etiology of the disease. i suspect that this may be one of those viruses where those infected think that they are healthy as it is only their neighbors who suffer from the symptoms. randy From owner-multi6@ops.ietf.org Wed Jun 20 13:23:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14946 for ; Wed, 20 Jun 2001 13:23:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15ClhC-000JoU-00 for multi6-data@psg.com; Wed, 20 Jun 2001 10:23:14 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15ClhB-000JoN-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 10:23:13 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 10:23:12 -0700 Message-ID: <003c01c0f9ad$aefa1fa0$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: References: <15145.9955.182872.840953@alpha-tli.procket.com><20010618173545.S5787@buddha.home.automagic.org><4.3.2.7.2.20010620100559.00c3e400@kahuna.telstra.net> Subject: An idea: GxSE Date: Wed, 20 Jun 2001 10:23:12 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 17:23:12.0690 (UTC) FILETIME=[AEFDC920:01C0F9AD] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've been tossing around the following basic approach to the multihoming/renumbering problem, and am wondering if folks think it is worth pursuing. Like GSE, the basic idea is to isolate site numbering from global numbering by allowing site border routers to rewrite prefixes as packets pass in and out of a site. Unlike GSE, however, the ID is not the sole identifier of the host. The full address is still the identifier, but multiple (full) addresses are used to identify the host. A packet received with any of the set of addresses identifies the host. In this sense, the idea is like SCTP's use of multiple addresses. I call this approach GxSE, to convey the idea that like GSE the address has global, site, and end-system address elements, but unlike GSE, addresses with multiple globals are used to identify a host (thus the 'x' after the G conveys a multiplier). There are multiple ways one could design GxSE. Here are the primary aspects of what I have in mind: Every host knows at least one (and typically only one) address for itself, called the self-known address (SK address). The SK address may or may not be globally routable, but must be globally unique. In addition to the SK address (from here on I talk as though there is only a single SK address---it should be understood that there can be multiple of them), there is a set of one or more globally routable addresses (GR addresses) for every host. The host does not need to know its GR addresses (nor do site-internal routers). All of the addresses (GR and SK) for a host have the same "site" and "ID" parts, but different "global" parts (aka "prefix"). An SK address may also be a GR address. The (publicly reachable) DNS entry for a host will typically contain all of the hosts' GR addresses. Each of the GR address prefixes of course represents that assigned by an ISP. There is a site border router attached to that ISP with that GR prefix. The site border router knows the SK prefixes for the site. (All hosts in a site do not necessarily have the same SK prefix, but if they don't then the site border router must know the SK prefix for every host.) The site border router knows all of the GR prefixes for the site, not just its own. (Again, all hosts in a site do not necessarily "have" the same GR prefixes, but if they don't then the site border router must know the GR prefixes for every host. Clearly it is better if all hosts have the same SK and GR prefixes, and this should be normal operation.) For every "connection" (where a connection is defined as a distinct address/protocol/port 5-tuple), the host keeps a list of (globally unique) addresses of the destination (or partner) host. It knows which of these is the SK address, and whether theSK address is routable or not. This full list identifies the host (not just the SK address). Two connections with partner hosts with different lists, even if they use the same SK address, are considered to be different hosts. Packets transmitted by a host contain its SK address as the source address, and one of the GR addresses of the partner host as the destination address. Typically the destination address will be that of the most recently received source address, but not necessarily. When the packet passes through the site border router, the router replaces the global prefix part of the SK address with that of the ISP to which it will route the packet. When a packet is received by a site border router incoming, the site border router replaces the GR prefix with the SK prefix of the destination host, and forwards the packet into the site. The list of addresses (GR and SK) is conveyed to partner hosts by an IPv6 extension header---the address-list extension. This header is typically added by the site border router as the packet exits the site. (It could also be added by the source host, but this would require the host to know its GR addresses which is the thing GxSE is trying to avoid. Nevertheless, a site could choose to operate this way.) The header is added typically only for the first packet sent in either direction (with the return header indicating whether the forward header was received). A GxSE-aware host would tell the site border router to add the address-list extension by attaching a different extension header (the "please add the address-list extension" extension, or address-list-trigger extension). Both extension headers are of the "if unknown, skip over this option and continue processing the header" type. The typical exchange would go like this: SH-->SSBR: |IPv6 head|ALT ext head|transport| SSBR->DH: |IPv6 head|ALT ext head|AL ext head|transport| DH->DSBR: |IPv6 head|ALT ext head (acks first ALT)|transport| DSBR->SH: |IPv6 head|ALT ext head|AL ext head|transport| SH->DH: |IPv6 head|transport| DH->SH: |IPv6 head|transport| (where SH=source host, SSBR=source site border router, DH and DSBR are same for destination, ALT=address-list-trigger, AL=address-list) This is the basic idea. Lots of unworked details.... For API, I imagine that the full list of addresses (GR+SK) gets handed up to the upper layer, if it cares to know. Pseudo-header checksums and IPsec would I suppose be based on the SK address only (not the GR addresses). Not sure how to deal with IPsec regarding the extension headers---due to inadequate understanding of this stuff. The extension header "handshake" needs to be worked through...might need to be 3-way etc. There are some destination address selection issues, to deal with the fact that SK addresses work within a site but not necessarily outside the site. Two hosts in the same site would want to use the SK address, not a GR address, when talking to each other. One approach is two-faced DNS. Another might be to go ahead and have DNS return the GR addresses, but after the address-list extension headers are exchanged, the hosts would recognize that they share the same SK prefix and could start using that (and subsequently bypassing the site border router). Note that IPv6 with site-local prefixes has the same sorts of issues. As for transition, site border routers need to know which hosts are GxSE aware and which aren't. For those that aren't the baseline behaviour would be for site border routers would agree to all use the same GR prefix on outgoing packets for each host. Obviously if the site border router with that GR crashes, then communications breaks, but this is no different from today's situation. The site border routers could potentially also try to proxy GxSE on behalf of the non-GxSE aware hosts (for the case where the partner host is GxSE aware). In this case, the site border router would need to keep enough state to know to attach the address-list extension on the initial packet only. (An address-list extension minus the address-list-trigger extension would convey to the destination host that the source host is non-GxSE aware, but the site border router is.) As for the issues brought up by draft-ietf-ipngwg-esd-analysis-05.txt, they largely don't apply because GxSE uses fully overloaded addresses, just more of them. For instance, there is no ID-to-address mapping issue because the ID is never used alone as the identifier. A host cannot pretend to be another host, in essence because the full set of addresses is what "identifies" a host, not a single address (and certainly not an ID alone). So, for instance, if a rogue host tries to pass itself off as having another host's SK address but its own GR address, it won't matter because the "identity" of the rogue host would be considered to be the whole list of addresses, and so wouldn't be confused with the "true" host (with the same SK address but the correct GR address). Note that GSxE doesn't prevent renumbering altogether---it would still be required when two sites merge. But renumbering would not be necessary because of changing providers. Comments? PF From owner-multi6@ops.ietf.org Wed Jun 20 13:50:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15841 for ; Wed, 20 Jun 2001 13:50:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cm6u-000KSB-00 for multi6-data@psg.com; Wed, 20 Jun 2001 10:49:48 -0700 Received: from istation.titania.net ([209.207.60.30] helo=monet.titania.net) by psg.com with esmtp (Exim 3.16 #1) id 15Cm6t-000KS5-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 10:49:47 -0700 Received: from [209.207.60.21] (dhcp-001.titania.net [209.207.60.21]) (authenticated) by monet.titania.net (8.11.4/8.11.3) with ESMTP id f5KHnXP65456 for ; Wed, 20 Jun 2001 17:49:33 GMT (envelope-from jtk@titania.net) Mime-Version: 1.0 X-Sender: jtk@mail.titania.net (Unverified) Message-Id: Date: Wed, 20 Jun 2001 17:49:27 +0000 To: multi6@ops.ietf.org From: "Joseph T. Klein" Subject: GSE vs. Multiple Addresses: pros & cons Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-multi6@ops.ietf.org Precedence: bulk Has anyone attempted to build working code for the GSE proposal? Any consensus on the pros and cons of these two proposals? -- Joseph T. Klein +1 414 915 7489 Senior Network Engineer jtk@titania.net Adelphia Business Solutions joseph.klein@adelphiacom.com "... the true value of the Internet is its connectedness ..." -- John W. Stewart III From owner-multi6@ops.ietf.org Wed Jun 20 14:11:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16673 for ; Wed, 20 Jun 2001 14:11:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CmS9-000Ktb-00 for multi6-data@psg.com; Wed, 20 Jun 2001 11:11:45 -0700 Received: from mercury.sun.com ([192.9.25.1]) by psg.com with esmtp (Exim 3.16 #1) id 15CmS8-000KtT-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 11:11:44 -0700 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA27832; Wed, 20 Jun 2001 11:11:41 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id LAA25060; Wed, 20 Jun 2001 11:11:54 -0700 (PDT) Received: from rouget.sun.com ([129.146.99.78]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f5KIAXG887902; Wed, 20 Jun 2001 11:10:33 -0700 (PDT) Message-Id: <5.1.0.14.0.20010620111514.02d54668@jurassic> X-Sender: durand@jurassic X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Jun 2001 11:16:14 -0700 To: "Paul Francis" , From: Alain Durand Subject: Re: An idea: GxSE In-Reply-To: <003c01c0f9ad$aefa1fa0$50030a0a@tahoenetworks.com> References: <15145.9955.182872.840953@alpha-tli.procket.com> <20010618173545.S5787@buddha.home.automagic.org> <4.3.2.7.2.20010620100559.00c3e400@kahuna.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 10:23 AM 6/20/2001 -0700, Paul Francis wrote: >Every host knows at least one (and typically only one) address for itself, >called the self-known address (SK address). The SK address may or may not >be globally routable, but must be globally unique. How can you build an SK with such properties? - Alain. From owner-multi6@ops.ietf.org Wed Jun 20 14:22:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17021 for ; Wed, 20 Jun 2001 14:22:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cmbx-000L6l-00 for multi6-data@psg.com; Wed, 20 Jun 2001 11:21:53 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15Cmbw-000L6e-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 11:21:52 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 11:21:52 -0700 Message-ID: <005801c0f9b5$e0a04310$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Paul Francis" , , "Alain Durand" References: <15145.9955.182872.840953@alpha-tli.procket.com> <20010618173545.S5787@buddha.home.automagic.org> <4.3.2.7.2.20010620100559.00c3e400@kahuna.telstra.net> <5.1.0.14.0.20010620111514.02d54668@jurassic> Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 11:21:51 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 18:21:52.0280 (UTC) FILETIME=[E0D49980:01C0F9B5] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > At 10:23 AM 6/20/2001 -0700, Paul Francis wrote: > >Every host knows at least one (and typically only one) address for itself, > >called the self-known address (SK address). The SK address may or may not > >be globally routable, but must be globally unique. > > How can you build an SK with such properties? > Simplest thing would be to get a prefix assigned from your ISP, but on a permanent basis. In other words, the ISP would leave that address assigned to you forever, even after you change ISPs. If you changed ISP, the prefix stops being routable, in the sense that a packet routed to that prefix would reach the ISP but then get dropped. As far as I know, there is no reason to need to independently distinguish a non-routable SK address from a GR address. If you object that ISPs won't do this...then have some other registry do it... PF From owner-multi6@ops.ietf.org Wed Jun 20 14:52:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17973 for ; Wed, 20 Jun 2001 14:52:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cn5u-000Lac-00 for multi6-data@psg.com; Wed, 20 Jun 2001 11:52:50 -0700 Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by psg.com with esmtp (Exim 3.16 #1) id 15Cn5t-000LZS-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 11:52:49 -0700 Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA42130; Wed, 20 Jun 2001 11:52:02 -0700 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA04928; Wed, 20 Jun 2001 11:51:41 -0700 Message-ID: <3B30EE90.E18DFC2A@hursley.ibm.com> Date: Wed, 20 Jun 2001 13:42:24 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Joseph T. Klein" CC: multi6@ops.ietf.org Subject: Re: GSE vs. Multiple Addresses: pros & cons References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Since we don't have an agreed requirements list, I don't see how we could have a pros and cons list yet. Brian "Joseph T. Klein" wrote: > > Has anyone attempted to build working code for the GSE proposal? > Any consensus on the pros and cons of these two proposals? > -- > Joseph T. Klein +1 414 915 7489 > Senior Network Engineer jtk@titania.net > Adelphia Business Solutions joseph.klein@adelphiacom.com From owner-multi6@ops.ietf.org Wed Jun 20 14:56:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18093 for ; Wed, 20 Jun 2001 14:56:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cn9h-000LcZ-00 for multi6-data@psg.com; Wed, 20 Jun 2001 11:56:45 -0700 Received: from mercury.sun.com ([192.9.25.1]) by psg.com with esmtp (Exim 3.16 #1) id 15Cn9g-000LcR-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 11:56:44 -0700 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA18637; Wed, 20 Jun 2001 11:56:40 -0700 (PDT) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20700; Wed, 20 Jun 2001 11:56:39 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.11.2+Sun/8.11.2) id f5KItFZ05882; Wed, 20 Jun 2001 11:55:15 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200106201855.f5KItFZ05882@locked.eng.sun.com> Subject: Re: An idea: GxSE In-Reply-To: <003c01c0f9ad$aefa1fa0$50030a0a@tahoenetworks.com> from Paul Francis at "Jun 20, 2001 10:23:12 am" To: Paul Francis Date: Wed, 20 Jun 2001 11:55:15 -0700 (PDT) CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul, TCP endpoint being associated with multiple addresses was discussed in draft-nikander-mobileip-homelessv6-01.txt. Isn't renumbering equivalent to a mobile node moving to a new foreign link ? In that case why can't renumbering event trigger all the TCP connections to generate a new secure message (known as binding update in mobile IPv6) to tell its peer about the new address ? After sending this message, TCP connections start using the new address. Why wouldn't this work ? If we are looking for a solution that would not change the end host's implementation, then the above is not suitable. So, is the requirement that the renumbering event should be completely transparent to the end hosts ? -mohan > > I've been tossing around the following basic approach to the > multihoming/renumbering problem, and am wondering if folks think it is worth > pursuing. > > Like GSE, the basic idea is to isolate site numbering from global numbering > by allowing site border routers to rewrite prefixes as packets pass in and > out of a site. Unlike GSE, however, the ID is not the sole identifier of > the host. The full address is still the identifier, but multiple (full) > addresses are used to identify the host. A packet received with any of the > set of addresses identifies the host. In this sense, the idea is like > SCTP's use of multiple addresses. > > I call this approach GxSE, to convey the idea that like GSE the address has > global, site, and end-system address elements, but unlike GSE, addresses > with multiple globals are used to identify a host (thus the 'x' after the G > conveys a multiplier). > > There are multiple ways one could design GxSE. Here are the primary aspects > of what I have in mind: > > Every host knows at least one (and typically only one) address for itself, > called the self-known address (SK address). The SK address may or may not > be globally routable, but must be globally unique. > > In addition to the SK address (from here on I talk as though there is only a > single SK address---it should be understood that there can be multiple of > them), there is a set of one or more globally routable addresses (GR > addresses) for every host. The host does not need to know its GR addresses > (nor do site-internal routers). All of the addresses (GR and SK) for a host > have the same "site" and "ID" parts, but different "global" parts (aka > "prefix"). An SK address may also be a GR address. The (publicly > reachable) DNS entry for a host will typically contain all of the hosts' GR > addresses. > > Each of the GR address prefixes of course represents that assigned by an > ISP. There is a site border router attached to that ISP with that GR > prefix. The site border router knows the SK prefixes for the site. (All > hosts in a site do not necessarily have the same SK prefix, but if they > don't then the site border router must know the SK prefix for every host.) > The site border router knows all of the GR prefixes for the site, not just > its own. (Again, all hosts in a site do not necessarily "have" the same GR > prefixes, but if they don't then the site border router must know the GR > prefixes for every host. Clearly it is better if all hosts have the same SK > and GR prefixes, and this should be normal operation.) > > For every "connection" (where a connection is defined as a distinct > address/protocol/port 5-tuple), the host keeps a list of (globally unique) > addresses of the destination (or partner) host. It knows which of these is > the SK address, and whether theSK address is routable or not. This full > list identifies the host (not just the SK address). Two connections with > partner hosts with different lists, even if they use the same SK address, > are considered to be different hosts. > > Packets transmitted by a host contain its SK address as the source address, > and one of the GR addresses of the partner host as the destination address. > Typically the destination address will be that of the most recently received > source address, but not necessarily. When the packet passes through the > site border router, the router replaces the global prefix part of the SK > address with that of the ISP to which it will route the packet. > > When a packet is received by a site border router incoming, the site border > router replaces the GR prefix with the SK prefix of the destination host, > and forwards the packet into the site. > > The list of addresses (GR and SK) is conveyed to partner hosts by an IPv6 > extension header---the address-list extension. This header is typically > added by the site border router as the packet exits the site. (It could > also be added by the source host, but this would require the host to know > its GR addresses which is the thing GxSE is trying to avoid. Nevertheless, > a site could choose to operate this way.) The header is added typically > only for the first packet sent in either direction (with the return header > indicating whether the forward header was received). A GxSE-aware host > would tell the site border router to add the address-list extension by > attaching a different extension header (the "please add the address-list > extension" extension, or address-list-trigger extension). Both extension > headers are of the "if unknown, skip over this option and continue > processing the header" type. > > The typical exchange would go like this: > > SH-->SSBR: |IPv6 head|ALT ext head|transport| > SSBR->DH: |IPv6 head|ALT ext head|AL ext head|transport| > DH->DSBR: |IPv6 head|ALT ext head (acks first ALT)|transport| > DSBR->SH: |IPv6 head|ALT ext head|AL ext head|transport| > SH->DH: |IPv6 head|transport| > DH->SH: |IPv6 head|transport| > > (where SH=source host, SSBR=source site border router, DH and DSBR are same > for destination, ALT=address-list-trigger, AL=address-list) > > > This is the basic idea. Lots of unworked details.... > > For API, I imagine that the full list of addresses (GR+SK) gets handed up to > the upper layer, if it cares to know. > > Pseudo-header checksums and IPsec would I suppose be based on the SK address > only (not the GR addresses). > > Not sure how to deal with IPsec regarding the extension headers---due to > inadequate understanding of this stuff. > > The extension header "handshake" needs to be worked through...might need to > be 3-way etc. > > There are some destination address selection issues, to deal with the fact > that SK addresses work within a site but not necessarily outside the site. > Two hosts in the same site would want to use the SK address, not a GR > address, when talking to each other. One approach is two-faced DNS. > Another might be to go ahead and have DNS return the GR addresses, but after > the address-list extension headers are exchanged, the hosts would recognize > that they share the same SK prefix and could start using that (and > subsequently bypassing the site border router). Note that IPv6 with > site-local prefixes has the same sorts of issues. > > As for transition, site border routers need to know which hosts are GxSE > aware and which aren't. For those that aren't the baseline behaviour would > be for site border routers would agree to all use the same GR prefix on > outgoing packets for each host. Obviously if the site border router with > that GR crashes, then communications breaks, but this is no different from > today's situation. The site border routers could potentially also try to > proxy GxSE on behalf of the non-GxSE aware hosts (for the case where the > partner host is GxSE aware). In this case, the site border router would > need to keep enough state to know to attach the address-list extension on > the initial packet only. (An address-list extension minus the > address-list-trigger extension would convey to the destination host that the > source host is non-GxSE aware, but the site border router is.) > > As for the issues brought up by draft-ietf-ipngwg-esd-analysis-05.txt, they > largely don't apply because GxSE uses fully overloaded addresses, just more > of them. For instance, there is no ID-to-address mapping issue because the > ID is never used alone as the identifier. A host cannot pretend to be > another host, in essence because the full set of addresses is what > "identifies" a host, not a single address (and certainly not an ID alone). > So, for instance, if a rogue host tries to pass itself off as having another > host's SK address but its own GR address, it won't matter because the > "identity" of the rogue host would be considered to be the whole list of > addresses, and so wouldn't be confused with the "true" host (with the same > SK address but the correct GR address). > > Note that GSxE doesn't prevent renumbering altogether---it would still be > required when two sites merge. But renumbering would not be necessary > because of changing providers. > > Comments? > > PF > > > From owner-multi6@ops.ietf.org Wed Jun 20 16:14:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20976 for ; Wed, 20 Jun 2001 16:14:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CoMT-000MzF-00 for multi6-data@psg.com; Wed, 20 Jun 2001 13:14:01 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15CoMR-000Mz8-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 13:14:00 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id PAA06791; Wed, 20 Jun 2001 15:14:11 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 20 Jun 2001 15:14:11 -0500 (CDT) From: "Jon (Taz) Mischo" To: Mohan Parthasarathy cc: Paul Francis , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <200106201855.f5KItFZ05882@locked.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Mohan, Paul- Unless I'm really misunderstanding something here, I was under the impression we're talking about fixed-site multihoming and address space change renumbering - the bane of every large site's existence. As such, I think we're not talking about mobility. We're talking about the v4 equivalent of a site moving from one /?? to another. Or, the BGP equivalent of changing your AS Path completely. Possibly millions of connections simultaneously moving. In this case, you really don't want a whole bunch of superfluous packets if you can avoid them. Now, this also happens to address transparent multihoming in the failover case, similar to how SCTP handles it, except instead of failing over to a new address, the GR prefix only changes. In plain terms, you're binding a socket between the SK addresses only, the rest is smoke and mirrors. Routing changes wouldn't really have a large impact, since the border routers are essentially rewriting the headers. Think of it as NAT with a 1:1 translation combined with the equivalent of a set of BGP announcements via several different AS's. If one route goes down, the GR prefix would change on one end of a connection, but the SK address would stay the same, and you're connected between SK's. BGP for hosts :) Again, that's how I'm reading this, I could very well be FAR off-base here. I was thinking about this, though...this could tie into BGP where you're announcing valid GR and SK prefix pairs. This sort of comes closer to the idea of landmark routing, where you basically are routing to a point closer to the destination without knowing where the destination really is, and then letting the landmark routers (the SSBR and DSBR) route you as it sees fit to go the rest of the way. In the event of a routing mishap, a specific GR/SK pair of an active connection would become invalid, forcing a change of GR mapping at the SSBR on the packet on the way out, transparent to the host. Furthermore, if a host was experiencing high packet loss, latency, or jitter, it might ask the SSBR to try a different GR prefix. It might be useful to allow the announcement of GR prefixes to declare certain QoS properties, so a host could request a GR that's designed for low latency or low jitter, for example. I digress, though. Just my $.02 and my interpretation. Always interested to know if I'm being silly. -Taz On Wed, 20 Jun 2001, Mohan Parthasarathy wrote: > Date: Wed, 20 Jun 2001 11:55:15 -0700 (PDT) > From: Mohan Parthasarathy > To: Paul Francis > Cc: multi6@ops.ietf.org > Subject: Re: An idea: GxSE > > Paul, > > TCP endpoint being associated with multiple addresses was > discussed in draft-nikander-mobileip-homelessv6-01.txt. > Isn't renumbering equivalent to a mobile node moving to > a new foreign link ? In that case why can't renumbering > event trigger all the TCP connections to generate a > new secure message (known as binding update in mobile IPv6) > to tell its peer about the new address ? After sending > this message, TCP connections start using the new address. > Why wouldn't this work ? > > If we are looking for a solution that would not change > the end host's implementation, then the above is not > suitable. So, is the requirement that the > renumbering event should be completely transparent to > the end hosts ? > > -mohan > > > > I've been tossing around the following basic approach to the > > multihoming/renumbering problem, and am wondering if folks think it is worth > > pursuing. > > > > Like GSE, the basic idea is to isolate site numbering from global numbering > > by allowing site border routers to rewrite prefixes as packets pass in and > > out of a site. Unlike GSE, however, the ID is not the sole identifier of > > the host. The full address is still the identifier, but multiple (full) > > addresses are used to identify the host. A packet received with any of the > > set of addresses identifies the host. In this sense, the idea is like > > SCTP's use of multiple addresses. > > > > I call this approach GxSE, to convey the idea that like GSE the address has > > global, site, and end-system address elements, but unlike GSE, addresses > > with multiple globals are used to identify a host (thus the 'x' after the G > > conveys a multiplier). > > > > There are multiple ways one could design GxSE. Here are the primary aspects > > of what I have in mind: > > > > Every host knows at least one (and typically only one) address for itself, > > called the self-known address (SK address). The SK address may or may not > > be globally routable, but must be globally unique. > > > > In addition to the SK address (from here on I talk as though there is only a > > single SK address---it should be understood that there can be multiple of > > them), there is a set of one or more globally routable addresses (GR > > addresses) for every host. The host does not need to know its GR addresses > > (nor do site-internal routers). All of the addresses (GR and SK) for a host > > have the same "site" and "ID" parts, but different "global" parts (aka > > "prefix"). An SK address may also be a GR address. The (publicly > > reachable) DNS entry for a host will typically contain all of the hosts' GR > > addresses. > > > > Each of the GR address prefixes of course represents that assigned by an > > ISP. There is a site border router attached to that ISP with that GR > > prefix. The site border router knows the SK prefixes for the site. (All > > hosts in a site do not necessarily have the same SK prefix, but if they > > don't then the site border router must know the SK prefix for every host.) > > The site border router knows all of the GR prefixes for the site, not just > > its own. (Again, all hosts in a site do not necessarily "have" the same GR > > prefixes, but if they don't then the site border router must know the GR > > prefixes for every host. Clearly it is better if all hosts have the same SK > > and GR prefixes, and this should be normal operation.) > > > > For every "connection" (where a connection is defined as a distinct > > address/protocol/port 5-tuple), the host keeps a list of (globally unique) > > addresses of the destination (or partner) host. It knows which of these is > > the SK address, and whether theSK address is routable or not. This full > > list identifies the host (not just the SK address). Two connections with > > partner hosts with different lists, even if they use the same SK address, > > are considered to be different hosts. > > > > Packets transmitted by a host contain its SK address as the source address, > > and one of the GR addresses of the partner host as the destination address. > > Typically the destination address will be that of the most recently received > > source address, but not necessarily. When the packet passes through the > > site border router, the router replaces the global prefix part of the SK > > address with that of the ISP to which it will route the packet. > > > > When a packet is received by a site border router incoming, the site border > > router replaces the GR prefix with the SK prefix of the destination host, > > and forwards the packet into the site. > > > > The list of addresses (GR and SK) is conveyed to partner hosts by an IPv6 > > extension header---the address-list extension. This header is typically > > added by the site border router as the packet exits the site. (It could > > also be added by the source host, but this would require the host to know > > its GR addresses which is the thing GxSE is trying to avoid. Nevertheless, > > a site could choose to operate this way.) The header is added typically > > only for the first packet sent in either direction (with the return header > > indicating whether the forward header was received). A GxSE-aware host > > would tell the site border router to add the address-list extension by > > attaching a different extension header (the "please add the address-list > > extension" extension, or address-list-trigger extension). Both extension > > headers are of the "if unknown, skip over this option and continue > > processing the header" type. > > > > The typical exchange would go like this: > > > > SH-->SSBR: |IPv6 head|ALT ext head|transport| > > SSBR->DH: |IPv6 head|ALT ext head|AL ext head|transport| > > DH->DSBR: |IPv6 head|ALT ext head (acks first ALT)|transport| > > DSBR->SH: |IPv6 head|ALT ext head|AL ext head|transport| > > SH->DH: |IPv6 head|transport| > > DH->SH: |IPv6 head|transport| > > > > (where SH=source host, SSBR=source site border router, DH and DSBR are same > > for destination, ALT=address-list-trigger, AL=address-list) > > > > > > This is the basic idea. Lots of unworked details.... > > > > For API, I imagine that the full list of addresses (GR+SK) gets handed up to > > the upper layer, if it cares to know. > > > > Pseudo-header checksums and IPsec would I suppose be based on the SK address > > only (not the GR addresses). > > > > Not sure how to deal with IPsec regarding the extension headers---due to > > inadequate understanding of this stuff. > > > > The extension header "handshake" needs to be worked through...might need to > > be 3-way etc. > > > > There are some destination address selection issues, to deal with the fact > > that SK addresses work within a site but not necessarily outside the site. > > Two hosts in the same site would want to use the SK address, not a GR > > address, when talking to each other. One approach is two-faced DNS. > > Another might be to go ahead and have DNS return the GR addresses, but after > > the address-list extension headers are exchanged, the hosts would recognize > > that they share the same SK prefix and could start using that (and > > subsequently bypassing the site border router). Note that IPv6 with > > site-local prefixes has the same sorts of issues. > > > > As for transition, site border routers need to know which hosts are GxSE > > aware and which aren't. For those that aren't the baseline behaviour would > > be for site border routers would agree to all use the same GR prefix on > > outgoing packets for each host. Obviously if the site border router with > > that GR crashes, then communications breaks, but this is no different from > > today's situation. The site border routers could potentially also try to > > proxy GxSE on behalf of the non-GxSE aware hosts (for the case where the > > partner host is GxSE aware). In this case, the site border router would > > need to keep enough state to know to attach the address-list extension on > > the initial packet only. (An address-list extension minus the > > address-list-trigger extension would convey to the destination host that the > > source host is non-GxSE aware, but the site border router is.) > > > > As for the issues brought up by draft-ietf-ipngwg-esd-analysis-05.txt, they > > largely don't apply because GxSE uses fully overloaded addresses, just more > > of them. For instance, there is no ID-to-address mapping issue because the > > ID is never used alone as the identifier. A host cannot pretend to be > > another host, in essence because the full set of addresses is what > > "identifies" a host, not a single address (and certainly not an ID alone). > > So, for instance, if a rogue host tries to pass itself off as having another > > host's SK address but its own GR address, it won't matter because the > > "identity" of the rogue host would be considered to be the whole list of > > addresses, and so wouldn't be confused with the "true" host (with the same > > SK address but the correct GR address). > > > > Note that GSxE doesn't prevent renumbering altogether---it would still be > > required when two sites merge. But renumbering would not be necessary > > because of changing providers. > > > > Comments? > > > > PF > > > > > > > > -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jun 20 16:15:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21012 for ; Wed, 20 Jun 2001 16:15:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CoOq-000N25-00 for multi6-data@psg.com; Wed, 20 Jun 2001 13:16:28 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CoOp-000N1z-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 13:16:27 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 13:16:27 -0700 Message-ID: <007001c0f9c5$e26e3200$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Mohan Parthasarathy" , "Paul Francis" Cc: References: <200106201855.f5KItFZ05882@locked.eng.sun.com> Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 13:16:26 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 20:16:27.0101 (UTC) FILETIME=[E28B08D0:01C0F9C5] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > TCP endpoint being associated with multiple addresses was > discussed in draft-nikander-mobileip-homelessv6-01.txt. > Isn't renumbering equivalent to a mobile node moving to > a new foreign link ? In that case why can't renumbering > event trigger all the TCP connections to generate a > new secure message (known as binding update in mobile IPv6) > to tell its peer about the new address ? After sending > this message, TCP connections start using the new address. > Why wouldn't this work ? Strictly speaking it would work. The need for secure messages makes it expensive, as does the need to explicitly renumber hosts. > > If we are looking for a solution that would not change > the end host's implementation, then the above is not > suitable. So, is the requirement that the > renumbering event should be completely transparent to > the end hosts ? > GxSE obviously changes the host implementation (though there is a migration path). But yes, the requirement here is that the renumbering event be transparent to end hosts (and also to internal routers). I think this is important for the same reasons that O'Dell expresses in GSE. I think that sites will not want to renumber, and will look for cheaper alternatives, of which there are two: 1. Convince the ISPs to advertise its prefix across the default-free routing zone (i.e., what we do today with IPv4) 2. Use NAT (also what we do with IPv4 today). The goal of GxSE is to provide a solution that is about as easy as NAT, but provides better functionality (mainly, connections survive in the face of the site border routing crashing). PF From owner-multi6@ops.ietf.org Wed Jun 20 16:28:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21454 for ; Wed, 20 Jun 2001 16:28:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Coai-000NEV-00 for multi6-data@psg.com; Wed, 20 Jun 2001 13:28:44 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.16 #1) id 15Coah-000NEM-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 13:28:43 -0700 Received: (qmail 13473 invoked by uid 100); 20 Jun 2001 20:28:34 -0000 Date: Wed, 20 Jun 2001 16:28:34 -0400 From: Joe Abley To: Brian E Carpenter Cc: "Joseph T. Klein" , multi6@ops.ietf.org Subject: Re: GSE vs. Multiple Addresses: pros & cons Message-ID: <20010620162833.B6104@buddha.home.automagic.org> References: <3B30EE90.E18DFC2A@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B30EE90.E18DFC2A@hursley.ibm.com>; from brian@hursley.ibm.com on Wed, Jun 20, 2001 at 01:42:24PM -0500 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, Jun 20, 2001 at 01:42:24PM -0500, Brian E Carpenter wrote: > Since we don't have an agreed requirements list, I don't see > how we could have a pros and cons list yet. Updating the requirements draft has been on my plate for a while; apologies for being so slack on this. I have the following notes for modifications to the current draft that I will attempt to make in the next few days. Please shout if there's something missing from this list that should be there. These are more-or-less in the order that mutt threaded them in (i.e. fairly arbitrary, but to some extent chronological). I also jotted down some references that I noticed on the way, and put them at the end. Joe GENERAL + replaces references to "autonomous systems" where use of BGP is not intended to be implied. RFC1918 defines an "enterprise". + mention the case of multiply attaching to the same provider + "connected to the Internet" might be better phrased as "part of the Internet" + security considerations + "load sharing" might be a better phrase than "load balancing" in some/most contexts + references to other work discussing scaling and convergence problems with the current v4 multi-homing architecture + "re-routing" needs to be used much more carefully, since we should not assume the best solution lies at the routing layer. It may pay to define a specific term to describe the network event which requires changes in traffic behaviours currently achieved by "re-routing" through a BGP withdrawal or announcement, like "re-homing event" or something + clarify that path selection based on (e.g.) TCP port numbers is not in scope (as suggested possibly in section 3.4 of the current draft) + specify that the multihoming solution *allows* host and app changes to enhance session survivability + make clear the distinction between the ability to establish a new transport-layer session and the ability to maintain existing transport-layer sessions following a re-homing event + Second sentence of the introduction might be re-written; Brian's suggestion is Current multihoming practice has been added on to the CIDR architecture [1], which assumes that routing table entries can be aggregated based upon a hierarchy of customers and service providers. + "inter-provider routing system" may be a good alternative to the phrase "routing protocols and routing hardware" + "Migration to IPv6.... exacerbate..." sentence in the introduction might be wr-written. Brian's suggestion is Migration to IPv6, which will allow unprecedented scaling of the number of potentially multihomed sites, will seriously exacerbate this stress unless a substantially different approach to multihoming is adopted. + make it clearer that load sharing is for resource balancing in the interests of performance; think about whether load sharing has specific requirements not covered elsewhere + section 3.4 might be re-written under the heading "Policy" instead of "Cost". Brian's suggestion is: 3.4 Policy A customer may choose to multihome for a variety of policy reasons outside technical scope (e.g. cost, acceptable use conditions, etc.) For example, customer C homed to ISP A may wish to shift traffic of a certain class or application, NNTP, for example, to ISP B as matter of policy. Any future multihoming proposals must provide support for multihoming for external policy reasons. + we might be more precise about what we mean by scalability of the multi-homing requirement. + specify that the multihoming solution *allows* host and app changes to enhance session survivability, rather than *requiring* it + Brian suggests additional sections: 3.7 Impact on routers The solution may require changes to IPv6 router implementations, but these changes must be either minor, or in the form of logically separate functions added to existing functions. Such changes must not prevent normal single-homed operation, and routers implementing these changes must be able to interoperate fully with hosts and routers not implementing them. 3.8 Impact on host stacks The solution must not destroy IPv6 connectivity for a legacy host implementing RFC 2373, RFC 2460, RFC 2553 and other basic IPv6 specifications current in 4/2001. That is to say, if a host can work in a single-homed site, it must still be able to work in a multihomed site, even if it cannot benefit from multihoming. It would be compatible with this requirement for such a host to lose connectivity if the site's primary ISP connection failed. If the solution requires changes to the host stack, these changes must be either minor, or in the form of logically separate functions added to existing functions. If the solution requires changes to the socket API and/or the transport layer, it must be possible to retain the original socket API and transport protocols in parallel, even if they cannot benefit from multihoming. 3.9 Operations and management It must be possible to monitor and configure the multihoming system. + think about whether the "overview of the current architecture" really belongs in this document, or whether it might be happier living some place else + "The solution may involve interaction between a site's hosts and its routing system; this interaction should be simple, scalable, and secureable." (Bill Sommerfeld) + Make it more clear as what the requirements actually *are*. It has been mentioned that the document assumes some context which should be spelt out. Make the draft look more like a requirements document, in fact. + The multihoming solution needs to include a mechanism for shifting specific traffic between prociders when more than one is available (Margaret). + Heuristics for a good design: simplicity, minimal impact on existing host implementations, ability to converge on new information quickly (Margaret). + Compatability requirements. Margaret suggested: Existing IPv6 host implementations, including - IPv6 host autoconfiguration - IPv6 over PPP? - DHCPv6 configuration? IPv6 Transition Mechanisms - Bump-in-the-Stack - Bump-in-the-API - NAT-PT - Tunneling mechanisms? - Others? Existing host-based transport layers: - TCP, UDP, etc. - SCTP? - Others? Existing IPv6 Routing Protocols? REFERENCES draft-nikander-mobileip-homelessv6-01.txt On Wed, 4 Apr 2001 10:10:00 -0700, Steve Deering wrote: > If this group is to pursue host-based or transport-layer multihoming, > you might want to look at some of the material presented at the Tokyo > interim meeting of the IPng working group in Sept/Oct 1999, fetchable > from . For example, > my "Overview of IP(v6) Multihoming Issues" is one attempt to > characterize the problem space and list a range of (increasingly > ambitious) goals one could set for host-based multihoming, and the > presentation from Peter Tattam entitled "Preserving Active TCP > Sessions" was one stab at enhancing TCP for multihoming. On Wed, 4 Apr 2001 20:02:01 +0200, Feico Dillema wrote: > As a side-note; Peter Tattam's proposal has been implemented by one of > our students in 1999 for the Kame stack on *BSD. If there's an > interest in the code (and maybe thesis too) to look at or maybe to > revive (on a more -current Kame stack) for actual experimentation, I > can put it online (and maybe revive it myself) once I'm back from a > (well-deserved! ;) vacation, i.e. in one or two weeks from now. Just > leave me a note, if you're interested... draft-ietf-sigtran-sctp-applicability-05.txt draft-stewart-sctpsocket-sigtran-02.txt draft-ohta-e2e-multihoming-01.txt From owner-multi6@ops.ietf.org Wed Jun 20 16:32:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21659 for ; Wed, 20 Jun 2001 16:32:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CofE-000NJa-00 for multi6-data@psg.com; Wed, 20 Jun 2001 13:33:24 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 15CofC-000NJM-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 13:33:22 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f5KKXEF91206; Wed, 20 Jun 2001 22:33:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 20 Jun 2001 22:32:59 +0200 (CEST) From: Iljitsch van Beijnum To: Paul Francis cc: multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <003c01c0f9ad$aefa1fa0$50030a0a@tahoenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 20 Jun 2001, Paul Francis wrote: > Like GSE, the basic idea is to isolate site numbering from global numbering > by allowing site border routers to rewrite prefixes as packets pass in and > out of a site. [...] > Comments? Well, I'm new here so I don't know to what extend all of this has been discussed before. But if we're going to push this problem to the end systems, aren't there any easier and more compatible ways to do it? Making a TCP session use multiple addresses would be a possibility. An option to negotiate extra IP addresses for a stream would certainly make TCP more complex but this could be reasonably backward compatible, it wouldn't require any changes in the IP layer or the routers and as a bonus it would allow multiple paths to be used concurrently for extra bandwidth. From owner-multi6@ops.ietf.org Wed Jun 20 16:42:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21972 for ; Wed, 20 Jun 2001 16:42:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Coou-000NY9-00 for multi6-data@psg.com; Wed, 20 Jun 2001 13:43:24 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15Coot-000NXv-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 13:43:23 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id PAA06842; Wed, 20 Jun 2001 15:43:31 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 20 Jun 2001 15:43:30 -0500 (CDT) From: "Jon (Taz) Mischo" To: Iljitsch van Beijnum cc: Paul Francis , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 20 Jun 2001, Iljitsch van Beijnum wrote: > Making a TCP session use multiple addresses would be a possibility. An > option to negotiate extra IP addresses for a stream would certainly make > TCP more complex but this could be reasonably backward compatible, it > wouldn't require any changes in the IP layer or the routers and as a bonus > it would allow multiple paths to be used concurrently for extra bandwidth. Why not just use SCTP? Why reinvent the wheel? -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jun 20 16:44:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22020 for ; Wed, 20 Jun 2001 16:44:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CoqO-000NaI-00 for multi6-data@psg.com; Wed, 20 Jun 2001 13:44:56 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CoqN-000Na8-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 13:44:55 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 13:44:55 -0700 Message-ID: <007901c0f9c9$dcac0e60$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 13:44:55 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 20:44:55.0473 (UTC) FILETIME=[DCCFEA10:01C0F9C9] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Unless I'm really misunderstanding something here, I was under the > impression we're talking about fixed-site multihoming and address space > change renumbering - the bane of every large site's existence. As such, I > think we're not talking about mobility. We're talking about the v4 Right, this is not about mobility. > new address, the GR prefix only changes. In plain terms, you're binding a > socket between the SK addresses only, the rest is smoke and mirrors. GxSE doesn't bind just the SK address to the socket, it binds the complete set of addresses (SK and GR) to the socket. > routers are essentially rewriting the headers. Think of it as NAT with a > 1:1 translation combined with the equivalent of a set of BGP announcements > via several different AS's. If one route goes down, the GR prefix would > change on one end of a connection, but the SK address would stay the same, > and you're connected between SK's. BGP for hosts :) You are reading too much into the SK. The purpose of the SK (I should have said this in my original note) is so that one end knows what the other end originally sent. Waving my hands a bit, this means that, if the host put the SK address in the application, the application at the other end would be able to interpret that SK as "the whole list of addresses bound to this connection". The NAT comparison is (sadly) appropriate. In particular, the site border router would have to go in and change application headers, for instance the SIP SDP, in order to change an SK address on the inside to a GR address on the outside. (Or I suppose I can imagine a sockets call in the host like getcurrentaddresslist() that sent a ping to the site border router or the partner host and got the list of addresses back, so that those applications that cared could learn it...though it begs the question what is the difference between this and renumbering...) Your BPG/landmark routing comparisons went over my head. PF From owner-multi6@ops.ietf.org Wed Jun 20 16:50:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22281 for ; Wed, 20 Jun 2001 16:50:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cow7-000Nkb-00 for multi6-data@psg.com; Wed, 20 Jun 2001 13:50:51 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15Cow6-000NkU-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 13:50:50 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 13:50:50 -0700 Message-ID: <008901c0f9ca$b02245c0$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Iljitsch van Beijnum" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 13:50:49 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 20:50:50.0263 (UTC) FILETIME=[B0489270:01C0F9CA] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Well, I'm new here so I don't know to what extend all of this has been > discussed before. I'm not sure either...I imagine a variant has come up in the past and been quickly stomped down... > > But if we're going to push this problem to the end systems, aren't there > any easier and more compatible ways to do it? > The multiple addresses/renumbering approach currently used by IPv6 pushes the problem to the end system. Other approaches that get border routers to coordinate and tunnel with each other push the problem to the middle. GxSE is somewhere in the middle...it doesn't push the whole problem to the host in the sense that the host doesn't need to be renumbered. But it does push much of the problem to the host. PF From owner-multi6@ops.ietf.org Wed Jun 20 16:53:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22378 for ; Wed, 20 Jun 2001 16:52:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Coyg-000Noi-00 for multi6-data@psg.com; Wed, 20 Jun 2001 13:53:30 -0700 Received: from mercury.sun.com ([192.9.25.1]) by psg.com with esmtp (Exim 3.16 #1) id 15Coye-000Noa-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 13:53:28 -0700 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12368; Wed, 20 Jun 2001 13:53:22 -0700 (PDT) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05835; Wed, 20 Jun 2001 13:53:17 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.11.2+Sun/8.11.2) id f5KKpsv05962; Wed, 20 Jun 2001 13:51:54 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200106202051.f5KKpsv05962@locked.eng.sun.com> Subject: Re: An idea: GxSE In-Reply-To: from "Jon (Taz) Mischo" at "Jun 20, 2001 03:43:30 pm" To: "Jon (Taz) Mischo" Date: Wed, 20 Jun 2001 13:51:54 -0700 (PDT) CC: Iljitsch van Beijnum , Paul Francis , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > On Wed, 20 Jun 2001, Iljitsch van Beijnum wrote: > > > Making a TCP session use multiple addresses would be a possibility. An > > option to negotiate extra IP addresses for a stream would certainly make > > TCP more complex but this could be reasonably backward compatible, it > > wouldn't require any changes in the IP layer or the routers and as a bonus > > it would allow multiple paths to be used concurrently for extra bandwidth. > > Why not just use SCTP? Why reinvent the wheel? > In SCTP, i think you have to know all the addresses at the beginning of the connection. Here, the new address is not known until renumbering happens. -mohan > -Taz > > -- > "Be liberal in what you accept, > and conservative in what you send." > --Jon Postel (1943-1998) RFC 1122, October 1989 > > From owner-multi6@ops.ietf.org Wed Jun 20 16:57:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22519 for ; Wed, 20 Jun 2001 16:57:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cp2o-000NtY-00 for multi6-data@psg.com; Wed, 20 Jun 2001 13:57:46 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15Cp2n-000NtP-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 13:57:45 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id PAA06888; Wed, 20 Jun 2001 15:57:59 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 20 Jun 2001 15:57:59 -0500 (CDT) From: "Jon (Taz) Mischo" To: Paul Francis cc: multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <007901c0f9c9$dcac0e60$50030a0a@tahoenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 20 Jun 2001, Paul Francis wrote: > GxSE doesn't bind just the SK address to the socket, it binds the complete > set of addresses (SK and GR) to the socket. Why not bind the SK if it's globally unique? There is 1 SK, and multiple GR's. Why not bind only the SK's and keep a table of valid GR's, so you know that it is truly valid? You already know that the GR you're bound to is wrong, why not assume the same for both sides, simplify the host software, and use the GR similar to an MPLS label (I hate to say it, but it reminds me a bit of exactly that...you just can't nest them). Basically, this would be taking a lesson from both BGP and MPLS, applying the simplest part to the host, letting the router do what it already does, changing far less overall, and still getting the same results. > You are reading too much into the SK. The purpose of the SK (I should have > said this in my original note) is so that one end knows what the other end > originally sent. Waving my hands a bit, this means that, if the host put > the SK address in the application, the application at the other end would be > able to interpret that SK as "the whole list of addresses bound to this > connection". This is the description of an SCTP association. This is almost exactly SCTP through NAT. My suggestion above takes a similar idea, but lets the network do most of the multihoming instead of the protocol. Otherwise you're basically talking about using NAT and SCTP together and calling it something else, with a few small tweaks and dropping the heartbeat, etc. This same effect can be generated using SCTP through NAT with ECN and a small change to allow ECN to trigger instant address switch instead of backing off first. > The NAT comparison is (sadly) appropriate. In particular, the site border > router would have to go in and change application headers, for instance the > SIP SDP, in order to change an SK address on the inside to a GR address on > the outside. (Or I suppose I can imagine a sockets call in the host like > getcurrentaddresslist() that sent a ping to the site border router or the > partner host and got the list of addresses back, so that those applications > that cared could learn it...though it begs the question what is the > difference between this and renumbering...) > > Your BPG/landmark routing comparisons went over my head. > > PF Hrmmm...a shame, because I think that's what would really make this very useful. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jun 20 16:59:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22587 for ; Wed, 20 Jun 2001 16:59:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cp57-000NzU-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:00:09 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15Cp56-000NzL-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:00:08 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:00:04 -0700 Message-ID: <009b01c0f9cb$fa9a2fe0$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Mohan Parthasarathy" , "Jon \(Taz\) Mischo" Cc: References: <200106202051.f5KKpsv05962@locked.eng.sun.com> Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:00:04 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:00:04.0403 (UTC) FILETIME=[FA93A030:01C0F9CB] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > > Why not just use SCTP? Why reinvent the wheel? > > > In SCTP, i think you have to know all the addresses at the beginning > of the connection. Here, the new address is not known until > renumbering happens. > Or more accurately, with sctp the source needs to know its own addresses at the beginning. This is what GxSE tries to avoid. Otherwise, though, the mechanism has a lot of similarities. PF From owner-multi6@ops.ietf.org Wed Jun 20 17:00:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22655 for ; Wed, 20 Jun 2001 17:00:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cp6R-000O24-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:01:31 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15Cp6Q-000O1y-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:01:30 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id QAA06915; Wed, 20 Jun 2001 16:01:39 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 20 Jun 2001 16:01:39 -0500 (CDT) From: "Jon (Taz) Mischo" To: Mohan Parthasarathy cc: Iljitsch van Beijnum , Paul Francis , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <200106202051.f5KKpsv05962@locked.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 20 Jun 2001, Mohan Parthasarathy wrote: > > Why not just use SCTP? Why reinvent the wheel? > > > In SCTP, i think you have to know all the addresses at the beginning > of the connection. Here, the new address is not known until > renumbering happens. Actually, here the address is known as a possibility all along, just isn't used, from my understanding. Furthermore, you learn all of those on the ACK to the first packet. SCTP uses a 4 way handshake and starts between 2 addresses, doing the about same thing...giving the other valid addresses, and learning the other side's other valid addresses. Also, with Add IP, you can add an address while the association is up. Basically, there's no advantage in that case, as I understand it. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jun 20 17:04:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22747 for ; Wed, 20 Jun 2001 17:04:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cp8q-000O6B-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:04:00 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15Cp8p-000O64-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:03:59 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id QAA06922; Wed, 20 Jun 2001 16:04:12 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 20 Jun 2001 16:04:12 -0500 (CDT) From: "Jon (Taz) Mischo" To: Paul Francis cc: Mohan Parthasarathy , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <009b01c0f9cb$fa9a2fe0$50030a0a@tahoenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 20 Jun 2001, Paul Francis wrote: > Or more accurately, with sctp the source needs to know its own addresses at > the beginning. This is what GxSE tries to avoid. Otherwise, though, the > mechanism has a lot of similarities. This is accurate. However, you can add IPs with the Add IP extension (that really is needed anyway, this is just more fuel for the fire, so to speak). -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jun 20 17:11:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22987 for ; Wed, 20 Jun 2001 17:11:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpGL-000OHx-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:11:45 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.16 #1) id 15CpGK-000OHq-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:11:44 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id 3368E823; Wed, 20 Jun 2001 23:11:41 +0200 (CEST) To: multi6@ops.ietf.org Subject: list archives, previous discussions [was Re: An idea: GxSE] Message-Id: <20010620211141.3368E823@sean.ebone.net> Date: Wed, 20 Jun 2001 23:11:41 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch van Beijnum and Paul Francis say: | > Well, I'm new here so I don't know to what extend all of this has been | > discussed before. | | I'm not sure either...I imagine a variant has come up in the past and been | quickly stomped down... The list archives live at ftp://ops.ietf.org/pub/lists/multi6* where you can read the whole history of the WG to date. It's not very long, since we aren't very old. Not being old also has the side-effect of having had too little time to stomp down anything. Thomas and I are working behind the scenes on the drafts which are under preparation and/or revision (thanks all for volunteering), and hope the conversation that ensues will be simultaneously interesting, constructive, and reasonably polite. Pointers to some WG resources, the charter, and the calendar we are trying to work to all can be found in the usual place for such things, viz. http://www.ietf.org/html.charters/multi6-charter.html Your co-chair, Sean. From owner-multi6@ops.ietf.org Wed Jun 20 17:16:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23206 for ; Wed, 20 Jun 2001 17:16:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 17:18:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23277 for ; Wed, 20 Jun 2001 17:18:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpNM-000OSj-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:19:00 -0700 Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by psg.com with esmtp (Exim 3.16 #1) id 15CpNL-000OSK-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:18:59 -0700 Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id OAA17706; Wed, 20 Jun 2001 14:18:28 -0700 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA20434; Wed, 20 Jun 2001 14:18:26 -0700 Message-ID: <3B31122B.41EB1161@hursley.ibm.com> Date: Wed, 20 Jun 2001 16:14:19 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Mohan Parthasarathy CC: Paul Francis , multi6@ops.ietf.org Subject: Re: An idea: GxSE References: <200106201855.f5KItFZ05882@locked.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Not all applications are TCP or SCTP. UDP applications don't (in principle at least) have enough state to respond to an address update, do they? Brian Mohan Parthasarathy wrote: > > Paul, > > TCP endpoint being associated with multiple addresses was > discussed in draft-nikander-mobileip-homelessv6-01.txt. > Isn't renumbering equivalent to a mobile node moving to > a new foreign link ? In that case why can't renumbering > event trigger all the TCP connections to generate a > new secure message (known as binding update in mobile IPv6) > to tell its peer about the new address ? After sending > this message, TCP connections start using the new address. > Why wouldn't this work ? > > If we are looking for a solution that would not change > the end host's implementation, then the above is not > suitable. So, is the requirement that the > renumbering event should be completely transparent to > the end hosts ? > > -mohan > > > > I've been tossing around the following basic approach to the > > multihoming/renumbering problem, and am wondering if folks think it is worth > > pursuing. > > > > Like GSE, the basic idea is to isolate site numbering from global numbering > > by allowing site border routers to rewrite prefixes as packets pass in and > > out of a site. Unlike GSE, however, the ID is not the sole identifier of > > the host. The full address is still the identifier, but multiple (full) > > addresses are used to identify the host. A packet received with any of the > > set of addresses identifies the host. In this sense, the idea is like > > SCTP's use of multiple addresses. > > > > I call this approach GxSE, to convey the idea that like GSE the address has > > global, site, and end-system address elements, but unlike GSE, addresses > > with multiple globals are used to identify a host (thus the 'x' after the G > > conveys a multiplier). > > > > There are multiple ways one could design GxSE. Here are the primary aspects > > of what I have in mind: > > > > Every host knows at least one (and typically only one) address for itself, > > called the self-known address (SK address). The SK address may or may not > > be globally routable, but must be globally unique. > > > > In addition to the SK address (from here on I talk as though there is only a > > single SK address---it should be understood that there can be multiple of > > them), there is a set of one or more globally routable addresses (GR > > addresses) for every host. The host does not need to know its GR addresses > > (nor do site-internal routers). All of the addresses (GR and SK) for a host > > have the same "site" and "ID" parts, but different "global" parts (aka > > "prefix"). An SK address may also be a GR address. The (publicly > > reachable) DNS entry for a host will typically contain all of the hosts' GR > > addresses. > > > > Each of the GR address prefixes of course represents that assigned by an > > ISP. There is a site border router attached to that ISP with that GR > > prefix. The site border router knows the SK prefixes for the site. (All > > hosts in a site do not necessarily have the same SK prefix, but if they > > don't then the site border router must know the SK prefix for every host.) > > The site border router knows all of the GR prefixes for the site, not just > > its own. (Again, all hosts in a site do not necessarily "have" the same GR > > prefixes, but if they don't then the site border router must know the GR > > prefixes for every host. Clearly it is better if all hosts have the same SK > > and GR prefixes, and this should be normal operation.) > > > > For every "connection" (where a connection is defined as a distinct > > address/protocol/port 5-tuple), the host keeps a list of (globally unique) > > addresses of the destination (or partner) host. It knows which of these is > > the SK address, and whether theSK address is routable or not. This full > > list identifies the host (not just the SK address). Two connections with > > partner hosts with different lists, even if they use the same SK address, > > are considered to be different hosts. > > > > Packets transmitted by a host contain its SK address as the source address, > > and one of the GR addresses of the partner host as the destination address. > > Typically the destination address will be that of the most recently received > > source address, but not necessarily. When the packet passes through the > > site border router, the router replaces the global prefix part of the SK > > address with that of the ISP to which it will route the packet. > > > > When a packet is received by a site border router incoming, the site border > > router replaces the GR prefix with the SK prefix of the destination host, > > and forwards the packet into the site. > > > > The list of addresses (GR and SK) is conveyed to partner hosts by an IPv6 > > extension header---the address-list extension. This header is typically > > added by the site border router as the packet exits the site. (It could > > also be added by the source host, but this would require the host to know > > its GR addresses which is the thing GxSE is trying to avoid. Nevertheless, > > a site could choose to operate this way.) The header is added typically > > only for the first packet sent in either direction (with the return header > > indicating whether the forward header was received). A GxSE-aware host > > would tell the site border router to add the address-list extension by > > attaching a different extension header (the "please add the address-list > > extension" extension, or address-list-trigger extension). Both extension > > headers are of the "if unknown, skip over this option and continue > > processing the header" type. > > > > The typical exchange would go like this: > > > > SH-->SSBR: |IPv6 head|ALT ext head|transport| > > SSBR->DH: |IPv6 head|ALT ext head|AL ext head|transport| > > DH->DSBR: |IPv6 head|ALT ext head (acks first ALT)|transport| > > DSBR->SH: |IPv6 head|ALT ext head|AL ext head|transport| > > SH->DH: |IPv6 head|transport| > > DH->SH: |IPv6 head|transport| > > > > (where SH=source host, SSBR=source site border router, DH and DSBR are same > > for destination, ALT=address-list-trigger, AL=address-list) > > > > > > This is the basic idea. Lots of unworked details.... > > > > For API, I imagine that the full list of addresses (GR+SK) gets handed up to > > the upper layer, if it cares to know. > > > > Pseudo-header checksums and IPsec would I suppose be based on the SK address > > only (not the GR addresses). > > > > Not sure how to deal with IPsec regarding the extension headers---due to > > inadequate understanding of this stuff. > > > > The extension header "handshake" needs to be worked through...might need to > > be 3-way etc. > > > > There are some destination address selection issues, to deal with the fact > > that SK addresses work within a site but not necessarily outside the site. > > Two hosts in the same site would want to use the SK address, not a GR > > address, when talking to each other. One approach is two-faced DNS. > > Another might be to go ahead and have DNS return the GR addresses, but after > > the address-list extension headers are exchanged, the hosts would recognize > > that they share the same SK prefix and could start using that (and > > subsequently bypassing the site border router). Note that IPv6 with > > site-local prefixes has the same sorts of issues. > > > > As for transition, site border routers need to know which hosts are GxSE > > aware and which aren't. For those that aren't the baseline behaviour would > > be for site border routers would agree to all use the same GR prefix on > > outgoing packets for each host. Obviously if the site border router with > > that GR crashes, then communications breaks, but this is no different from > > today's situation. The site border routers could potentially also try to > > proxy GxSE on behalf of the non-GxSE aware hosts (for the case where the > > partner host is GxSE aware). In this case, the site border router would > > need to keep enough state to know to attach the address-list extension on > > the initial packet only. (An address-list extension minus the > > address-list-trigger extension would convey to the destination host that the > > source host is non-GxSE aware, but the site border router is.) > > > > As for the issues brought up by draft-ietf-ipngwg-esd-analysis-05.txt, they > > largely don't apply because GxSE uses fully overloaded addresses, just more > > of them. For instance, there is no ID-to-address mapping issue because the > > ID is never used alone as the identifier. A host cannot pretend to be > > another host, in essence because the full set of addresses is what > > "identifies" a host, not a single address (and certainly not an ID alone). > > So, for instance, if a rogue host tries to pass itself off as having another > > host's SK address but its own GR address, it won't matter because the > > "identity" of the rogue host would be considered to be the whole list of > > addresses, and so wouldn't be confused with the "true" host (with the same > > SK address but the correct GR address). > > > > Note that GSxE doesn't prevent renumbering altogether---it would still be > > required when two sites merge. But renumbering would not be necessary > > because of changing providers. > > > > Comments? > > > > PF From owner-multi6@ops.ietf.org Wed Jun 20 17:30:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23590 for ; Wed, 20 Jun 2001 17:30:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 17:37:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23784 for ; Wed, 20 Jun 2001 17:37:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpQB-000OX2-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:21:55 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpQB-000OWw-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:21:55 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:21:54 -0700 Message-ID: <00cf01c0f9cf$079844e0$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: , "Sean Doran" References: <20010620211141.3368E823@sean.ebone.net> Subject: Re: list archives, previous discussions [was Re: An idea: GxSE] Date: Wed, 20 Jun 2001 14:21:54 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:21:54.0686 (UTC) FILETIME=[0790F1E0:01C0F9CF] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | > | I'm not sure either...I imagine a variant has come up in the past and been > | quickly stomped down... > > The list archives live at ftp://ops.ietf.org/pub/lists/multi6* > where you can read the whole history of the WG to date. > It's not very long, since we aren't very old. Not being > old also has the side-effect of having had too little time > to stomp down anything. > I have read through much of the multi6 archives. I didn't mean to suggest that multi6 stomped anything down...I was figuring it happened back in the days when GSE was being proposed... PF From owner-multi6@ops.ietf.org Wed Jun 20 17:37:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23795 for ; Wed, 20 Jun 2001 17:37:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpGL-000OHx-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:11:45 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.16 #1) id 15CpGK-000OHq-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:11:44 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id 3368E823; Wed, 20 Jun 2001 23:11:41 +0200 (CEST) To: multi6@ops.ietf.org Subject: list archives, previous discussions [was Re: An idea: GxSE] Message-Id: <20010620211141.3368E823@sean.ebone.net> Date: Wed, 20 Jun 2001 23:11:41 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch van Beijnum and Paul Francis say: | > Well, I'm new here so I don't know to what extend all of this has been | > discussed before. | | I'm not sure either...I imagine a variant has come up in the past and been | quickly stomped down... The list archives live at ftp://ops.ietf.org/pub/lists/multi6* where you can read the whole history of the WG to date. It's not very long, since we aren't very old. Not being old also has the side-effect of having had too little time to stomp down anything. Thomas and I are working behind the scenes on the drafts which are under preparation and/or revision (thanks all for volunteering), and hope the conversation that ensues will be simultaneously interesting, constructive, and reasonably polite. Pointers to some WG resources, the charter, and the calendar we are trying to work to all can be found in the usual place for such things, viz. http://www.ietf.org/html.charters/multi6-charter.html Your co-chair, Sean. From owner-multi6@ops.ietf.org Wed Jun 20 17:37:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23806 for ; Wed, 20 Jun 2001 17:37:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpeB-000OtY-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:36:23 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpeA-000OtR-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:36:23 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:36:22 -0700 Message-ID: <00da01c0f9d1$0cc63010$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Mohan Parthasarathy" , "Paul Francis" Cc: "Jon \\\(Taz\\\) Mischo" , References: <200106202126.f5KLQgw05987@locked.eng.sun.com> Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:36:22 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:36:22.0365 (UTC) FILETIME=[0CBE40D0:01C0F9D1] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > I don't understand how you would know about the whole list of addresses. > I assume that the trigger to add the list of addresses happens during > the beginning of the connection. Renumbering can happen always after > that so that your peer does not know your new address. Am i missing > something ? > yeah. GxSE does not try to bind to new addresses that appear after a connection is already established. New prefixes cannot be used by old connections. I don't think maintaining connections in the face of new prefix assignments is a very important problem to solve. It won't happen *that* frequently, and overlapping being-added prefixes and being-deleted prefixes for a time will suffice for all but the longest-lived connections. PF From owner-multi6@ops.ietf.org Wed Jun 20 17:38:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23822 for ; Wed, 20 Jun 2001 17:38:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpWE-000Oh3-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:28:10 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.16 #1) id 15CpWE-000Ogx-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:28:10 -0700 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24938; Wed, 20 Jun 2001 15:28:05 -0600 (MDT) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24681; Wed, 20 Jun 2001 14:28:06 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.11.2+Sun/8.11.2) id f5KLQgw05987; Wed, 20 Jun 2001 14:26:42 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200106202126.f5KLQgw05987@locked.eng.sun.com> Subject: Re: An idea: GxSE In-Reply-To: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> from Paul Francis at "Jun 20, 2001 02:15:15 pm" To: Paul Francis Date: Wed, 20 Jun 2001 14:26:42 -0700 (PDT) CC: "Jon \\(Taz\\) Mischo" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > > Could you give me a clear explanation of your suggestion? I don't > understand it. > > > Also, regarding Add IP (another message from you about SCTP came in while I > reply to this one...), you can't do this securely unless there is a trust > relationship. Otherwise any spoofer can send a packet out of the blue with > its GR and somebody else's SK and hijack the connection. Maybe this is what > you mean by "bind to the SK only"---allow any GR to be used once the SK is > established? > > The reason GxSE binds the whole list of addresses from the beginning is to > prevent spoofing. If we have the luxury of establishing a secure > relationship between both ends, then may as well use HIP. > I don't understand how you would know about the whole list of addresses. I assume that the trigger to add the list of addresses happens during the beginning of the connection. Renumbering can happen always after that so that your peer does not know your new address. Am i missing something ? -mohan > > > From owner-multi6@ops.ietf.org Wed Jun 20 17:38:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23836 for ; Wed, 20 Jun 2001 17:38:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 17:38:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23850 for ; Wed, 20 Jun 2001 17:38:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpTZ-000Ocf-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:25:25 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15CpTY-000OcZ-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:25:24 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15CpTW-000ONl-00; Wed, 20 Jun 2001 14:25:22 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Geoff Huston Cc: multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming References: <15145.9955.182872.840953@alpha-tli.procket.com> <4.3.2.7.2.20010620093712.00bb66f0@kahuna.telstra.net> Message-Id: Date: Wed, 20 Jun 2001 14:25:22 -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > how do you communication that information to the remote system in a way > that manages to constrain the choices available to the remote system to > match your desired policy? when 'remote' means they have no technical or financial incentive to do you the favor, then 'constrain' seems far too strong a term. > BUT you also have to work out how to overlay policy / TE onto of this > connectivity fabric i have an arch-capitalist friend who i would normally expect to step in here and observe that it is not clear that you HAVE TO. in fact, it might be in the interest of only a few. perhaps, when it comes to traveling this road, he has fallen arches, or maybe it is feet of clay, or fear of capital punishment. :-) randy From owner-multi6@ops.ietf.org Wed Jun 20 17:39:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23869 for ; Wed, 20 Jun 2001 17:39:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cphq-000Owr-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:40:10 -0700 Received: from mercury.sun.com ([192.9.25.1]) by psg.com with esmtp (Exim 3.16 #1) id 15Cphq-000Owl-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:40:10 -0700 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03612; Wed, 20 Jun 2001 14:40:00 -0700 (PDT) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA27362; Wed, 20 Jun 2001 14:39:57 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.11.2+Sun/8.11.2) id f5KLcXf05996; Wed, 20 Jun 2001 14:38:33 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200106202138.f5KLcXf05996@locked.eng.sun.com> Subject: Re: An idea: GxSE In-Reply-To: <3B31122B.41EB1161@hursley.ibm.com> from Brian E Carpenter at "Jun 20, 2001 04:14:19 pm" To: Brian E Carpenter Date: Wed, 20 Jun 2001 14:38:33 -0700 (PDT) CC: Mohan Parthasarathy , Paul Francis , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Not all applications are TCP or SCTP. UDP applications don't > (in principle at least) have enough state to respond to > an address update, do they? > Some UDP applications do a connect(). In this case there is state in the kernel which can react to an address update. In other cases it would be a problem. Do you mean to say that UDP applications might remember about destinations it needs to communicate with, for a long time ? Most of the documents about renumbering talks only about TCP connection surviving and so we are a bit carried away here i guess.. -mohan o > Brian > > Mohan Parthasarathy wrote: > > > > Paul, > > > > TCP endpoint being associated with multiple addresses was > > discussed in draft-nikander-mobileip-homelessv6-01.txt. > > Isn't renumbering equivalent to a mobile node moving to > > a new foreign link ? In that case why can't renumbering > > event trigger all the TCP connections to generate a > > new secure message (known as binding update in mobile IPv6) > > to tell its peer about the new address ? After sending > > this message, TCP connections start using the new address. > > Why wouldn't this work ? > > > > If we are looking for a solution that would not change > > the end host's implementation, then the above is not > > suitable. So, is the requirement that the > > renumbering event should be completely transparent to > > the end hosts ? > > > > -mohan > > > > > > I've been tossing around the following basic approach to the > > > multihoming/renumbering problem, and am wondering if folks think it is worth > > > pursuing. > > > > > > Like GSE, the basic idea is to isolate site numbering from global numbering > > > by allowing site border routers to rewrite prefixes as packets pass in and > > > out of a site. Unlike GSE, however, the ID is not the sole identifier of > > > the host. The full address is still the identifier, but multiple (full) > > > addresses are used to identify the host. A packet received with any of the > > > set of addresses identifies the host. In this sense, the idea is like > > > SCTP's use of multiple addresses. > > > > > > I call this approach GxSE, to convey the idea that like GSE the address has > > > global, site, and end-system address elements, but unlike GSE, addresses > > > with multiple globals are used to identify a host (thus the 'x' after the G > > > conveys a multiplier). > > > > > > There are multiple ways one could design GxSE. Here are the primary aspects > > > of what I have in mind: > > > > > > Every host knows at least one (and typically only one) address for itself, > > > called the self-known address (SK address). The SK address may or may not > > > be globally routable, but must be globally unique. > > > > > > In addition to the SK address (from here on I talk as though there is only a > > > single SK address---it should be understood that there can be multiple of > > > them), there is a set of one or more globally routable addresses (GR > > > addresses) for every host. The host does not need to know its GR addresses > > > (nor do site-internal routers). All of the addresses (GR and SK) for a host > > > have the same "site" and "ID" parts, but different "global" parts (aka > > > "prefix"). An SK address may also be a GR address. The (publicly > > > reachable) DNS entry for a host will typically contain all of the hosts' GR > > > addresses. > > > > > > Each of the GR address prefixes of course represents that assigned by an > > > ISP. There is a site border router attached to that ISP with that GR > > > prefix. The site border router knows the SK prefixes for the site. (All > > > hosts in a site do not necessarily have the same SK prefix, but if they > > > don't then the site border router must know the SK prefix for every host.) > > > The site border router knows all of the GR prefixes for the site, not just > > > its own. (Again, all hosts in a site do not necessarily "have" the same GR > > > prefixes, but if they don't then the site border router must know the GR > > > prefixes for every host. Clearly it is better if all hosts have the same SK > > > and GR prefixes, and this should be normal operation.) > > > > > > For every "connection" (where a connection is defined as a distinct > > > address/protocol/port 5-tuple), the host keeps a list of (globally unique) > > > addresses of the destination (or partner) host. It knows which of these is > > > the SK address, and whether theSK address is routable or not. This full > > > list identifies the host (not just the SK address). Two connections with > > > partner hosts with different lists, even if they use the same SK address, > > > are considered to be different hosts. > > > > > > Packets transmitted by a host contain its SK address as the source address, > > > and one of the GR addresses of the partner host as the destination address. > > > Typically the destination address will be that of the most recently received > > > source address, but not necessarily. When the packet passes through the > > > site border router, the router replaces the global prefix part of the SK > > > address with that of the ISP to which it will route the packet. > > > > > > When a packet is received by a site border router incoming, the site border > > > router replaces the GR prefix with the SK prefix of the destination host, > > > and forwards the packet into the site. > > > > > > The list of addresses (GR and SK) is conveyed to partner hosts by an IPv6 > > > extension header---the address-list extension. This header is typically > > > added by the site border router as the packet exits the site. (It could > > > also be added by the source host, but this would require the host to know > > > its GR addresses which is the thing GxSE is trying to avoid. Nevertheless, > > > a site could choose to operate this way.) The header is added typically > > > only for the first packet sent in either direction (with the return header > > > indicating whether the forward header was received). A GxSE-aware host > > > would tell the site border router to add the address-list extension by > > > attaching a different extension header (the "please add the address-list > > > extension" extension, or address-list-trigger extension). Both extension > > > headers are of the "if unknown, skip over this option and continue > > > processing the header" type. > > > > > > The typical exchange would go like this: > > > > > > SH-->SSBR: |IPv6 head|ALT ext head|transport| > > > SSBR->DH: |IPv6 head|ALT ext head|AL ext head|transport| > > > DH->DSBR: |IPv6 head|ALT ext head (acks first ALT)|transport| > > > DSBR->SH: |IPv6 head|ALT ext head|AL ext head|transport| > > > SH->DH: |IPv6 head|transport| > > > DH->SH: |IPv6 head|transport| > > > > > > (where SH=source host, SSBR=source site border router, DH and DSBR are same > > > for destination, ALT=address-list-trigger, AL=address-list) > > > > > > > > > This is the basic idea. Lots of unworked details.... > > > > > > For API, I imagine that the full list of addresses (GR+SK) gets handed up to > > > the upper layer, if it cares to know. > > > > > > Pseudo-header checksums and IPsec would I suppose be based on the SK address > > > only (not the GR addresses). > > > > > > Not sure how to deal with IPsec regarding the extension headers---due to > > > inadequate understanding of this stuff. > > > > > > The extension header "handshake" needs to be worked through...might need to > > > be 3-way etc. > > > > > > There are some destination address selection issues, to deal with the fact > > > that SK addresses work within a site but not necessarily outside the site. > > > Two hosts in the same site would want to use the SK address, not a GR > > > address, when talking to each other. One approach is two-faced DNS. > > > Another might be to go ahead and have DNS return the GR addresses, but after > > > the address-list extension headers are exchanged, the hosts would recognize > > > that they share the same SK prefix and could start using that (and > > > subsequently bypassing the site border router). Note that IPv6 with > > > site-local prefixes has the same sorts of issues. > > > > > > As for transition, site border routers need to know which hosts are GxSE > > > aware and which aren't. For those that aren't the baseline behaviour would > > > be for site border routers would agree to all use the same GR prefix on > > > outgoing packets for each host. Obviously if the site border router with > > > that GR crashes, then communications breaks, but this is no different from > > > today's situation. The site border routers could potentially also try to > > > proxy GxSE on behalf of the non-GxSE aware hosts (for the case where the > > > partner host is GxSE aware). In this case, the site border router would > > > need to keep enough state to know to attach the address-list extension on > > > the initial packet only. (An address-list extension minus the > > > address-list-trigger extension would convey to the destination host that the > > > source host is non-GxSE aware, but the site border router is.) > > > > > > As for the issues brought up by draft-ietf-ipngwg-esd-analysis-05.txt, they > > > largely don't apply because GxSE uses fully overloaded addresses, just more > > > of them. For instance, there is no ID-to-address mapping issue because the > > > ID is never used alone as the identifier. A host cannot pretend to be > > > another host, in essence because the full set of addresses is what > > > "identifies" a host, not a single address (and certainly not an ID alone). > > > So, for instance, if a rogue host tries to pass itself off as having another > > > host's SK address but its own GR address, it won't matter because the > > > "identity" of the rogue host would be considered to be the whole list of > > > addresses, and so wouldn't be confused with the "true" host (with the same > > > SK address but the correct GR address). > > > > > > Note that GSxE doesn't prevent renumbering altogether---it would still be > > > required when two sites merge. But renumbering would not be necessary > > > because of changing providers. > > > > > > Comments? > > > > > > PF From owner-multi6@ops.ietf.org Wed Jun 20 17:40:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23888 for ; Wed, 20 Jun 2001 17:40:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 17:47:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24081 for ; Wed, 20 Jun 2001 17:47:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 17:52:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24280 for ; Wed, 20 Jun 2001 17:52:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 17:58:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24366 for ; Wed, 20 Jun 2001 17:58:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 18:03:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24501 for ; Wed, 20 Jun 2001 18:03:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 18:08:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24621 for ; Wed, 20 Jun 2001 18:08:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CprX-000PBO-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:50:11 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.16 #1) id 15CprW-000PBI-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:50:10 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id 1458388D; Wed, 20 Jun 2001 23:50:09 +0200 (CEST) To: multi6@ops.ietf.org Subject: Re: An idea: GxSE Message-Id: <20010620215009.1458388D@sean.ebone.net> Date: Wed, 20 Jun 2001 23:50:09 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Mohan Parthasarathy | > Why not just use SCTP? Why reinvent the wheel? | | In SCTP, i think you have to know all the addresses at the beginning | of the connection. Here, the new address is not known until | renumbering happens. My interpretation of Ohta-san's draft proposal (see list archives) understands that it calls for the addition and subtraction of addresses *known inside the host* during the lifetime of a connection, based on learned information about the behaviour of nonlocal topology. In other words, Mohan is correct if "here" refers to Ohta-san's proposal. Although his draft is the only one we've gotten so far, I do not think we would want to exclude other GSE-like proposals, should the arrive upon us in the form of a draft (hint, hint, hint to everyone). By contrast, Paul Francis's idea (GxSE) proposes that things inside multihomed sites do not need to know their entire set of addresses, but that a nameserver will ("typically") know all of them. To me, this is Ohta-san's proposal with the topology knowledge pushed one or more hops away from the host, and as a result of which introduces an architecture which requires some small changes by host-developers (e.g., don't make assumptions about the end-to-endianness of the GR (RG in Mike O'Dell's GSE) when doing things like checksums or encodings of host addresses in upper-layer protocols). PF notes this, Ohta notes the opposite in his draft. Without making any sort of judgement, I'd like to suggest that although our initial volunteer team hasn't finished the draft of a requirements doc yet, at least a couple of them read the list. I suspect that (if it's not there already), the reqs will indicate a desire to support a wide variety of "transport-layer" protocols. Thus, while we're waiting on the reqs, I think it'd be particularly nice if proposals (however informal) somehow could be "fitted-into" -- or at least take into consideration -- TCP, UDP, and so forth, and ideally make implementing/managing IGPs (in the sites themselves or in their respective inverse trees of providers) very much more difficult than today (in v4 or v6). Shim approaches (like SCTP) are not the only -- or even necessarily the best (though maybe they are) -- way of taking these possible-requirements into consideration. In other words, it's far too early to exclude prima facie any new ideas, or any old ones, either. Yours wishy-washily, Sean. From owner-multi6@ops.ietf.org Wed Jun 20 18:08:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24632 for ; Wed, 20 Jun 2001 18:08:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 18:14:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24750 for ; Wed, 20 Jun 2001 18:14:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 18:20:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24913 for ; Wed, 20 Jun 2001 18:20:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 18:25:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25049 for ; Wed, 20 Jun 2001 18:25:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cpsd-000PCp-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:51:19 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15Cpsc-000PCj-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:51:18 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id QAA07044; Wed, 20 Jun 2001 16:51:32 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 20 Jun 2001 16:51:32 -0500 (CDT) From: "Jon (Taz) Mischo" To: Paul Francis cc: Mohan Parthasarathy , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <00da01c0f9d1$0cc63010$50030a0a@tahoenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 20 Jun 2001, Paul Francis wrote: > > the beginning of the connection. Renumbering can happen always after > > that so that your peer does not know your new address. Am i missing > > something ? > > > > yeah. GxSE does not try to bind to new addresses that appear after a > connection is already established. New prefixes cannot be used by old > connections. I don't think maintaining connections in the face of new > prefix assignments is a very important problem to solve. It won't happen > *that* frequently, and overlapping being-added prefixes and being-deleted > prefixes for a time will suffice for all but the longest-lived connections. To reiterate for you, Mohan, we're not taling about mobility. We're talking about large-scale changes, not one or two hosts, but thousands of hosts. If a new prefix is added, it doesn't affect a few hosts, it affects a large subnet. I'm hoping Paul and Alain remember who I am, but I don't think I've ever met you, Mohan. I'm Jon Mischo (nickname is Taz) from Motorola's Advanced Network Technologies group. Anyway, I'm involved in ROHC, somtimes in TSVWG (for SCTP) and used to be involved in Seamoby and Sigtran (also for SCTP). Mobile IP greatly impacts my world (for better or for worse) due to the nature of our work. I'm also a fan of Nuclear War :P Oh, and Alain gets mad when I read and edit drafts in the back of his WG meetings, so don't do that, he doesn't like it ;) Introductions out of the way. As usual, I digress...so back to the point. Mobile IP handles the case of a host moving around on a network. Here we're addressing the issues of a network moving around on a backbone and in address space. What we're trying to solve for here is how to keep a host unaware that there have been sweeping network changes, including its own address, while still giving it the ability to operate as if nothing happened, with confidence that its sessions aren't being hijacked. And Paul...I'm working on a reply to your previous email...just have to think about how to say it best. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jun 20 18:25:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25060 for ; Wed, 20 Jun 2001 18:25:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 18:33:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25124 for ; Wed, 20 Jun 2001 18:33:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cq37-000PRb-00 for multi6-data@psg.com; Wed, 20 Jun 2001 15:02:09 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.16 #1) id 15Cq36-000PRS-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 15:02:09 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id 81C50888; Thu, 21 Jun 2001 00:02:02 +0200 (CEST) To: multi6@ops.ietf.org Subject: Re: list archives, previous discussions [was Re: An idea: GxSE] Message-Id: <20010620220202.81C50888@sean.ebone.net> Date: Thu, 21 Jun 2001 00:02:02 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Paul Francis writes - | I didn't mean to suggest that multi6 stomped anything down...I was figuring | it happened back in the days when GSE was being proposed... Many of us have some history, and multi6 is an attempt to restart tabula rasa, and make some progress on site multihoming for IPv6, despite wide-ranging disagreements on other (v6, v4, ...) matters. While there may be some of eyeball-rolling at old arguments on all sides, the hope is that we don't throw tac nukes on this list, and that water under the bridge doesn't poison the well of discussion in this WG. Yours mixing cliched metaphors until the cows come home, Sean. From owner-multi6@ops.ietf.org Wed Jun 20 18:33:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25135 for ; Wed, 20 Jun 2001 18:33:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 18:33:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25145 for ; Wed, 20 Jun 2001 18:33:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CqI4-000PoP-00 for multi6-data@psg.com; Wed, 20 Jun 2001 15:17:36 -0700 Received: from mercury.sun.com ([192.9.25.1]) by psg.com with esmtp (Exim 3.16 #1) id 15CqI3-000PoJ-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 15:17:35 -0700 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19927; Wed, 20 Jun 2001 15:17:29 -0700 (PDT) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27460; Wed, 20 Jun 2001 15:17:29 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.11.2+Sun/8.11.2) id f5KMG5c06016; Wed, 20 Jun 2001 15:16:05 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200106202216.f5KMG5c06016@locked.eng.sun.com> Subject: Re: An idea: GxSE In-Reply-To: from "Jon (Taz) Mischo" at "Jun 20, 2001 04:51:32 pm" To: "Jon (Taz) Mischo" Date: Wed, 20 Jun 2001 15:16:05 -0700 (PDT) CC: Paul Francis , Mohan Parthasarathy , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > On Wed, 20 Jun 2001, Paul Francis wrote: > > > > the beginning of the connection. Renumbering can happen always after > > > that so that your peer does not know your new address. Am i missing > > > something ? > > > > > > > yeah. GxSE does not try to bind to new addresses that appear after a > > connection is already established. New prefixes cannot be used by old > > connections. I don't think maintaining connections in the face of new > > prefix assignments is a very important problem to solve. It won't happen > > *that* frequently, and overlapping being-added prefixes and being-deleted > > prefixes for a time will suffice for all but the longest-lived connections. > > To reiterate for you, Mohan, we're not taling about mobility. We're > talking about large-scale changes, not one or two hosts, but thousands of > hosts. If a new prefix is added, it doesn't affect a few hosts, it > affects a large subnet. > Sure. I was only trying to draw an analogy i.e Mobile IPv6 which i am familiar with. Are you saying that we are not interested in solving the above mentioned problem ? > I'm hoping Paul and Alain remember who I am, but I don't think I've ever > met you, Mohan. I'm Jon Mischo (nickname is Taz) from Motorola's Advanced > Network Technologies group. Anyway, I'm involved in ROHC, somtimes in > TSVWG (for SCTP) and used to be involved in Seamoby and Sigtran (also for > SCTP). Mobile IP greatly impacts my world (for better or for worse) due > to the nature of our work. I'm also a fan of Nuclear War :P Oh, and Alain > gets mad when I read and edit drafts in the back of his WG meetings, so > don't do that, he doesn't like it ;) Introductions out of the way. As > usual, I digress...so back to the point. > > Mobile IP handles the case of a host moving around on a network. Here > we're addressing the issues of a network moving around on a backbone and > in address space. What we're trying to solve for here is how to keep a When you are moving around, you are getting new prefixes and the old prefixes will not be valid after sometime. (The difference between this and mobility is that the old prefix is considered to be valid in mobility) > host unaware that there have been sweeping network changes, including its > own address, while still giving it the ability to operate as if nothing > happened, with confidence that its sessions aren't being hijacked. > What do you mean by keeping the host unaware ? Does it mean that you don't want the renumbering event to be known to the end hosts ? It will be known without which it can't configure new addresses. So, i am missing something. -mohan > And Paul...I'm working on a reply to your previous email...just have to > think about how to say it best. > > -Taz > > -- > "Be liberal in what you accept, > and conservative in what you send." > --Jon Postel (1943-1998) RFC 1122, October 1989 > From owner-multi6@ops.ietf.org Wed Jun 20 18:34:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25184 for ; Wed, 20 Jun 2001 18:34:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 18:41:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25232 for ; Wed, 20 Jun 2001 18:41:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cq9w-000Pcw-00 for multi6-data@psg.com; Wed, 20 Jun 2001 15:09:12 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15Cq9v-000Pcq-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 15:09:11 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id RAA07097; Wed, 20 Jun 2001 17:09:18 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 20 Jun 2001 17:09:18 -0500 (CDT) From: "Jon (Taz) Mischo" To: Mohan Parthasarathy cc: Brian E Carpenter , Paul Francis , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <200106202138.f5KLcXf05996@locked.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a good argument for what I was talking about, actually. Either way, though, with UDP you'd just use a tunable timeout parameter. There are MANY UDP applications that remember about their destinations for a long time. This is the idea behind using RTP for VoIP, as well as how many network video games, etc work, to give some examples. UDP doesn't mean short connections, it just means more loss-tolerant or more time-sensitive connections. The key difference is that the vast majority of state for UDP is kept in the client. In the case of GxSE, you'd need to implement something closer to what I was talking about for UDP to work effectively, since the host would not be keeping state, and you'd have to have the DSBR rewrite the headers since the host wouldn't be maintaining a list of valid GR/SK pairs. Again, this is where SK binding comes into play. Really, here you would have a lookup that returned the GR addresses and you'd have your SK address. One of the GR addresses would then be chosen to attempt the connection. Once you reach the far host, you'd request the SK for that host. You'd then reference that SK in your packets, with confidence that your SSBR would map both your SK and his SK to their appropriate GR/SK pairs. It may even be appropriate to use the GR returned by the lookup to query your SSBR for a local SK style address it knows about. Then you are sending packets between an SK address and a virtual SK (basically you're doing reverse NAT here). The SSBR is then doing all of your remapping. I think this is right...I really think we're approaching the point where we should start writing a draft or two just to flesh out the ideas, so we can all understand them. On Wed, 20 Jun 2001, Mohan Parthasarathy wrote: > > Not all applications are TCP or SCTP. UDP applications don't > > (in principle at least) have enough state to respond to > > an address update, do they? > > > Some UDP applications do a connect(). In this case there is state > in the kernel which can react to an address update. In other > cases it would be a problem. Do you mean to say that UDP > applications might remember about destinations it needs > to communicate with, for a long time ? > > Most of the documents about renumbering talks only about > TCP connection surviving and so we are a bit carried > away here i guess.. > > -mohan > > o > > Brian > > > > Mohan Parthasarathy wrote: > > > > > > Paul, > > > > > > TCP endpoint being associated with multiple addresses was > > > discussed in draft-nikander-mobileip-homelessv6-01.txt. > > > Isn't renumbering equivalent to a mobile node moving to > > > a new foreign link ? In that case why can't renumbering > > > event trigger all the TCP connections to generate a > > > new secure message (known as binding update in mobile IPv6) > > > to tell its peer about the new address ? After sending > > > this message, TCP connections start using the new address. > > > Why wouldn't this work ? > > > > > > If we are looking for a solution that would not change > > > the end host's implementation, then the above is not > > > suitable. So, is the requirement that the > > > renumbering event should be completely transparent to > > > the end hosts ? > > > > > > -mohan > > > > > > > > I've been tossing around the following basic approach to the > > > > multihoming/renumbering problem, and am wondering if folks think it is worth > > > > pursuing. > > > > > > > > Like GSE, the basic idea is to isolate site numbering from global numbering > > > > by allowing site border routers to rewrite prefixes as packets pass in and > > > > out of a site. Unlike GSE, however, the ID is not the sole identifier of > > > > the host. The full address is still the identifier, but multiple (full) > > > > addresses are used to identify the host. A packet received with any of the > > > > set of addresses identifies the host. In this sense, the idea is like > > > > SCTP's use of multiple addresses. > > > > > > > > I call this approach GxSE, to convey the idea that like GSE the address has > > > > global, site, and end-system address elements, but unlike GSE, addresses > > > > with multiple globals are used to identify a host (thus the 'x' after the G > > > > conveys a multiplier). > > > > > > > > There are multiple ways one could design GxSE. Here are the primary aspects > > > > of what I have in mind: > > > > > > > > Every host knows at least one (and typically only one) address for itself, > > > > called the self-known address (SK address). The SK address may or may not > > > > be globally routable, but must be globally unique. > > > > > > > > In addition to the SK address (from here on I talk as though there is only a > > > > single SK address---it should be understood that there can be multiple of > > > > them), there is a set of one or more globally routable addresses (GR > > > > addresses) for every host. The host does not need to know its GR addresses > > > > (nor do site-internal routers). All of the addresses (GR and SK) for a host > > > > have the same "site" and "ID" parts, but different "global" parts (aka > > > > "prefix"). An SK address may also be a GR address. The (publicly > > > > reachable) DNS entry for a host will typically contain all of the hosts' GR > > > > addresses. > > > > > > > > Each of the GR address prefixes of course represents that assigned by an > > > > ISP. There is a site border router attached to that ISP with that GR > > > > prefix. The site border router knows the SK prefixes for the site. (All > > > > hosts in a site do not necessarily have the same SK prefix, but if they > > > > don't then the site border router must know the SK prefix for every host.) > > > > The site border router knows all of the GR prefixes for the site, not just > > > > its own. (Again, all hosts in a site do not necessarily "have" the same GR > > > > prefixes, but if they don't then the site border router must know the GR > > > > prefixes for every host. Clearly it is better if all hosts have the same SK > > > > and GR prefixes, and this should be normal operation.) > > > > > > > > For every "connection" (where a connection is defined as a distinct > > > > address/protocol/port 5-tuple), the host keeps a list of (globally unique) > > > > addresses of the destination (or partner) host. It knows which of these is > > > > the SK address, and whether theSK address is routable or not. This full > > > > list identifies the host (not just the SK address). Two connections with > > > > partner hosts with different lists, even if they use the same SK address, > > > > are considered to be different hosts. > > > > > > > > Packets transmitted by a host contain its SK address as the source address, > > > > and one of the GR addresses of the partner host as the destination address. > > > > Typically the destination address will be that of the most recently received > > > > source address, but not necessarily. When the packet passes through the > > > > site border router, the router replaces the global prefix part of the SK > > > > address with that of the ISP to which it will route the packet. > > > > > > > > When a packet is received by a site border router incoming, the site border > > > > router replaces the GR prefix with the SK prefix of the destination host, > > > > and forwards the packet into the site. > > > > > > > > The list of addresses (GR and SK) is conveyed to partner hosts by an IPv6 > > > > extension header---the address-list extension. This header is typically > > > > added by the site border router as the packet exits the site. (It could > > > > also be added by the source host, but this would require the host to know > > > > its GR addresses which is the thing GxSE is trying to avoid. Nevertheless, > > > > a site could choose to operate this way.) The header is added typically > > > > only for the first packet sent in either direction (with the return header > > > > indicating whether the forward header was received). A GxSE-aware host > > > > would tell the site border router to add the address-list extension by > > > > attaching a different extension header (the "please add the address-list > > > > extension" extension, or address-list-trigger extension). Both extension > > > > headers are of the "if unknown, skip over this option and continue > > > > processing the header" type. > > > > > > > > The typical exchange would go like this: > > > > > > > > SH-->SSBR: |IPv6 head|ALT ext head|transport| > > > > SSBR->DH: |IPv6 head|ALT ext head|AL ext head|transport| > > > > DH->DSBR: |IPv6 head|ALT ext head (acks first ALT)|transport| > > > > DSBR->SH: |IPv6 head|ALT ext head|AL ext head|transport| > > > > SH->DH: |IPv6 head|transport| > > > > DH->SH: |IPv6 head|transport| > > > > > > > > (where SH=source host, SSBR=source site border router, DH and DSBR are same > > > > for destination, ALT=address-list-trigger, AL=address-list) > > > > > > > > > > > > This is the basic idea. Lots of unworked details.... > > > > > > > > For API, I imagine that the full list of addresses (GR+SK) gets handed up to > > > > the upper layer, if it cares to know. > > > > > > > > Pseudo-header checksums and IPsec would I suppose be based on the SK address > > > > only (not the GR addresses). > > > > > > > > Not sure how to deal with IPsec regarding the extension headers---due to > > > > inadequate understanding of this stuff. > > > > > > > > The extension header "handshake" needs to be worked through...might need to > > > > be 3-way etc. > > > > > > > > There are some destination address selection issues, to deal with the fact > > > > that SK addresses work within a site but not necessarily outside the site. > > > > Two hosts in the same site would want to use the SK address, not a GR > > > > address, when talking to each other. One approach is two-faced DNS. > > > > Another might be to go ahead and have DNS return the GR addresses, but after > > > > the address-list extension headers are exchanged, the hosts would recognize > > > > that they share the same SK prefix and could start using that (and > > > > subsequently bypassing the site border router). Note that IPv6 with > > > > site-local prefixes has the same sorts of issues. > > > > > > > > As for transition, site border routers need to know which hosts are GxSE > > > > aware and which aren't. For those that aren't the baseline behaviour would > > > > be for site border routers would agree to all use the same GR prefix on > > > > outgoing packets for each host. Obviously if the site border router with > > > > that GR crashes, then communications breaks, but this is no different from > > > > today's situation. The site border routers could potentially also try to > > > > proxy GxSE on behalf of the non-GxSE aware hosts (for the case where the > > > > partner host is GxSE aware). In this case, the site border router would > > > > need to keep enough state to know to attach the address-list extension on > > > > the initial packet only. (An address-list extension minus the > > > > address-list-trigger extension would convey to the destination host that the > > > > source host is non-GxSE aware, but the site border router is.) > > > > > > > > As for the issues brought up by draft-ietf-ipngwg-esd-analysis-05.txt, they > > > > largely don't apply because GxSE uses fully overloaded addresses, just more > > > > of them. For instance, there is no ID-to-address mapping issue because the > > > > ID is never used alone as the identifier. A host cannot pretend to be > > > > another host, in essence because the full set of addresses is what > > > > "identifies" a host, not a single address (and certainly not an ID alone). > > > > So, for instance, if a rogue host tries to pass itself off as having another > > > > host's SK address but its own GR address, it won't matter because the > > > > "identity" of the rogue host would be considered to be the whole list of > > > > addresses, and so wouldn't be confused with the "true" host (with the same > > > > SK address but the correct GR address). > > > > > > > > Note that GSxE doesn't prevent renumbering altogether---it would still be > > > > required when two sites merge. But renumbering would not be necessary > > > > because of changing providers. > > > > > > > > Comments? > > > > > > > > PF > > -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jun 20 18:41:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25243 for ; Wed, 20 Jun 2001 18:41:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 18:46:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25302 for ; Wed, 20 Jun 2001 18:46:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 18:54:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25499 for ; Wed, 20 Jun 2001 18:54:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CqRO-00001j-00 for multi6-data@psg.com; Wed, 20 Jun 2001 15:27:14 -0700 Received: from mako1.telstra.net ([203.50.0.28]) by psg.com with esmtp (Exim 3.16 #1) id 15CqRN-00001c-00; Wed, 20 Jun 2001 15:27:13 -0700 Received: from tecra.telstra.net (gorp.telstra.net [203.50.0.66]) by mako1.telstra.net (8.11.3/8.11.1) with ESMTP id f5KMR9B29256; Thu, 21 Jun 2001 08:27:09 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20010621081240.00c40140@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Jun 2001 08:26:24 +1000 To: Randy Bush From: Geoff Huston Subject: Re: Regionally aggregatable address space for multihoming Cc: multi6@ops.ietf.org In-Reply-To: References: <15145.9955.182872.840953@alpha-tli.procket.com> <4.3.2.7.2.20010620093712.00bb66f0@kahuna.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk > > how do you communication that information to the remote system in a way > > that manages to constrain the choices available to the remote system to > > match your desired policy? > >when 'remote' means they have no technical or financial incentive to do you >the favor, then 'constrain' seems far too strong a term. Indeed when favours run out, then constraining choices is precisely what is going on. i.e. there are no technical or financial incentives for the party who is sending the traffic to take the destination's preferred path, but there are financial incentives for the destination to coerce the sender to make a particular choice. Interdomain traffic policy always struck me as a variant of the Dyjkstra (sp?) brides problem - the starting case is that the sender has unilateral choice as path choice to the destination, and the destination responds to this by attempting to constrain the sender's choice set. This game is being played out in the inter-AS space because, like the commons, there is no impediment to abusing this common space. > > BUT you also have to work out how to overlay policy / TE onto of this > > connectivity fabric > >i have an arch-capitalist friend who i would normally expect to step in >here and observe that it is not clear that you HAVE TO. in fact, it might >be in the interest of only a few. perhaps, when it comes to traveling this >road, he has fallen arches, or maybe it is feet of clay, or fear of capital >punishment. :-) If you want the interdomain connectivity protocols to scale then separating out policy / TE 'negotiation' into a distinct protocol interaction would address some of the concerns regarding scaling of the inter-domain space as a connectivity protocol convergence issue. The imperative of "HAVE" comes for broader issues surrounding the integrity of the whole, as represented the sum of all these individual policy-based transactions. As an addendum to this posting I would have to say that I think I'm abusing the tolerance of the multi6 list with this topic, and I promise that I'll stop. Please accept my apologies if you already think I've gone well out into the weeds topic-wise. As interesting as these topics are to me, I think that I've taken up more than enough of the multi6 crew's time, and I try and stay focused on multi6 in further postings to this list. Randy, Do you have any suggestions as to an appropriate list to continue this discussion? Is ptomaine willing to tolerate a continuation of this discussion? thanks, Geoff From owner-multi6@ops.ietf.org Wed Jun 20 18:54:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25503 for ; Wed, 20 Jun 2001 18:54:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CqaT-0000DQ-00 for multi6-data@psg.com; Wed, 20 Jun 2001 15:36:37 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15CqaS-0000DK-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 15:36:36 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15CqaP-0000LN-00; Wed, 20 Jun 2001 15:36:33 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Geoff Huston Cc: multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming References: <15145.9955.182872.840953@alpha-tli.procket.com> <4.3.2.7.2.20010620093712.00bb66f0@kahuna.telstra.net> <4.3.2.7.2.20010621081240.00c40140@kahuna.telstra.net> Message-Id: Date: Wed, 20 Jun 2001 15:36:33 -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Randy, Do you have any suggestions as to an appropriate list to continue > this discussion? Is ptomaine willing to tolerate a continuation of this > discussion? i suspect 'encourage' would be a more appropriate word. randy From owner-multi6@ops.ietf.org Wed Jun 20 18:54:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25516 for ; Wed, 20 Jun 2001 18:54:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CqRQ-00001u-00 for multi6-data@psg.com; Wed, 20 Jun 2001 15:27:16 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15CqRP-00001n-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 15:27:16 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id RAA07145; Wed, 20 Jun 2001 17:27:18 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 20 Jun 2001 17:27:18 -0500 (CDT) From: "Jon (Taz) Mischo" To: Sean Doran cc: multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <20010620215009.1458388D@sean.ebone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 20 Jun 2001, Sean Doran wrote: > Thus, while we're waiting on the reqs, I think it'd be particularly > nice if proposals (however informal) somehow could be "fitted-into" -- > or at least take into consideration -- TCP, UDP, and so forth, > and ideally make implementing/managing IGPs (in the sites themselves > or in their respective inverse trees of providers) very much more > difficult than today (in v4 or v6). Shim approaches (like SCTP) I KNOW you meant the opposite here, Sean :) You want IGPs to be easier, not difficult, RIGHT? :) > are not the only -- or even necessarily the best (though maybe they are) -- > way of taking these possible-requirements into consideration. SCTP isn't a shim, but some people want to use it that way. It's really good for some connections, but I'm tired of hearing people advocate it in bad situations :P However, reinventing the wheel is bad sometimes, too. Part of the idea GxSE induced in my cluttered head was the notion that this doesn't have to be at the border routers only. Border routers are often very heavily loaded. Announcing valid GR/SK pairings via BGP or the like and then propagating them into an IGP (OSPF/IS-IS) would allow you to make translations further into the network, without renumbering. Basically, you could make the network renumber itself. If this is done properly, you could keep the intelligence at the edge, completely avoid renumbering, AND get better routing/multihoming performance overall. This COULD be a win-win situation, I just think we have to look at it from all angles and proceed very carefully. Not quite so wishy-washily yours, -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jun 20 18:54:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25525 for ; Wed, 20 Jun 2001 18:54:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 19:00:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25656 for ; Wed, 20 Jun 2001 19:00:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 19:06:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25778 for ; Wed, 20 Jun 2001 19:06:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 19:11:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25937 for ; Wed, 20 Jun 2001 19:11:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 19:18:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26110 for ; Wed, 20 Jun 2001 19:18:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 19:24:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26242 for ; Wed, 20 Jun 2001 19:24:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cr4j-0000n8-00 for multi6-data@psg.com; Wed, 20 Jun 2001 16:07:53 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15Cr4h-0000n0-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 16:07:51 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id SAA07222; Wed, 20 Jun 2001 18:08:05 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 20 Jun 2001 18:08:05 -0500 (CDT) From: "Jon (Taz) Mischo" To: Mohan Parthasarathy cc: Paul Francis , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <200106202216.f5KMG5c06016@locked.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 20 Jun 2001, Mohan Parthasarathy wrote: > > To reiterate for you, Mohan, we're not taling about mobility. We're > > talking about large-scale changes, not one or two hosts, but thousands of > > hosts. If a new prefix is added, it doesn't affect a few hosts, it > > affects a large subnet. > > > Sure. I was only trying to draw an analogy i.e Mobile IPv6 which i am > familiar with. Are you saying that we are not interested in solving > the above mentioned problem ? Understandable. But yes, that's what I'm saying. What we're discussing here isn't mobility, and we're not designing for mobility. However, it does have some good benefits for mobility. > > Mobile IP handles the case of a host moving around on a network. Here > > we're addressing the issues of a network moving around on a backbone and > > in address space. What we're trying to solve for here is how to keep a > > When you are moving around, you are getting new prefixes and the old > prefixes will not be valid after sometime. (The difference between > this and mobility is that the old prefix is considered to be valid > in mobility) You're not moving around a lot. Again, this isn't mobility. This is often the result of a circuit or router going down in the case of multihoming. In thse situations, the prefix is never invalidated, it's just useless for a while. In the case of renumbering, if you have a protocol that does a good job of distributing the prefix information, it is pushed far enough out that you don't have to worry. Furthermore, we're talking about address space that's unique but doesn't have to be routable. This way you know it will be rewritten, but the host doesn't really care about that. In some cases the space may be routable and you may still own it, but you aren't using it anymore, in favor of better aggregation and routing. One of the biggest nightmares in the service provider field (I know, before I was in R&D I was a network engineer for a very large ISP) is renumbering because you have a region that's grown and you either have to add a new subnet and grow your tables due to the aggregation you've lost, or renumber that region into a larger subnet you have. In this scenario, you would just change the GR the space fell into, keeping the same SK, so the host doesn't know it's somewhere else in the network. > > host unaware that there have been sweeping network changes, including its > > own address, while still giving it the ability to operate as if nothing > > happened, with confidence that its sessions aren't being hijacked. > > > What do you mean by keeping the host unaware ? Does it mean that > you don't want the renumbering event to be known to the end hosts ? > It will be known without which it can't configure new addresses. > So, i am missing something. That's exactly what it means. The host doesn't configure new addresses. In SCTP it can, but we're talking about GxSE, where there are routers further upstream that are doing the remapping/rewriting for you. The host doesn't have to know. Of course, Sean's point of this requiring a different checksum scenario is very true. We'd have to move to a checksum scenario closer to what UDP-lite uses, where you don't have a single checksum for the entire packet, but actually break the packet up into portions that are reliable and unreliable. Obviously the addresses in a packet are completely unreliable for checksum purposes in this scenario, and need either to have their own simple checksum that's verified and recomputed at every rewrite, or you just checksum as many bytes from the header as will stay the same regardless, and pray what you get at the other end makes sense. Of course, if it doesn't, it'll likely be rejected anyway. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jun 20 19:24:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26249 for ; Wed, 20 Jun 2001 19:24:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cr3x-0000lK-00 for multi6-data@psg.com; Wed, 20 Jun 2001 16:07:05 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.16 #1) id 15Cr3w-0000lB-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 16:07:04 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id AAA8888D; Thu, 21 Jun 2001 01:07:02 +0200 (CEST) To: multi6@ops.ietf.org Subject: Re: Regionally aggregatable address space for multihoming Message-Id: <20010620230702.AAA8888D@sean.ebone.net> Date: Thu, 21 Jun 2001 01:07:02 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Randy Bush writes to Geoff Huston: | > Randy, Do you have any suggestions as to an appropriate list to continue | > this discussion? Is ptomaine willing to tolerate a continuation of this | > discussion? | | i suspect 'encourage' would be a more appropriate word. Swapping the WG hat for the RG hat, I invite you to discuss this and ANY other Internet-routing-related topic on the open irtf-rr interest list, details of which can be found at http://www.irtf.org/charters/routing.html or http://puck.nether.net/irtf-rr/ Swapping back, multi6 is probably best off focusing on site multihoming for v6, although, Geoff, please bear in mind that it is reasonable to argue that some form of traffic management might/ought to find its way into the forthcoming requirements draft, or the forthcoming "how it's done in v4 today" draft, or both. Sean. From owner-multi6@ops.ietf.org Wed Jun 20 19:24:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26259 for ; Wed, 20 Jun 2001 19:24:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 19:30:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26369 for ; Wed, 20 Jun 2001 19:30:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 19:36:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26432 for ; Wed, 20 Jun 2001 19:36:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 19:42:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26552 for ; Wed, 20 Jun 2001 19:42:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 19:48:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26641 for ; Wed, 20 Jun 2001 19:48:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 19:53:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26704 for ; Wed, 20 Jun 2001 19:53:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 19:59:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26837 for ; Wed, 20 Jun 2001 19:59:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 20:05:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26995 for ; Wed, 20 Jun 2001 20:05:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 20:11:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27074 for ; Wed, 20 Jun 2001 20:11:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 20:27:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27249 for ; Wed, 20 Jun 2001 20:27:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 20:32:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27309 for ; Wed, 20 Jun 2001 20:32:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 20:48:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27445 for ; Wed, 20 Jun 2001 20:48:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 20:55:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27584 for ; Wed, 20 Jun 2001 20:55:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 21:01:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27667 for ; Wed, 20 Jun 2001 21:01:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 21:09:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27772 for ; Wed, 20 Jun 2001 21:09:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 21:15:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27827 for ; Wed, 20 Jun 2001 21:15:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 21:22:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27888 for ; Wed, 20 Jun 2001 21:22:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 21:28:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27939 for ; Wed, 20 Jun 2001 21:28:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 21:34:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28321 for ; Wed, 20 Jun 2001 21:34:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 21:50:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29115 for ; Wed, 20 Jun 2001 21:50:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 21:56:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29188 for ; Wed, 20 Jun 2001 21:56:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 22:02:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29260 for ; Wed, 20 Jun 2001 22:02:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 22:08:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29322 for ; Wed, 20 Jun 2001 22:08:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 22:14:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29445 for ; Wed, 20 Jun 2001 22:14:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 22:20:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29505 for ; Wed, 20 Jun 2001 22:20:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 22:26:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29592 for ; Wed, 20 Jun 2001 22:26:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 22:32:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00623 for ; Wed, 20 Jun 2001 22:32:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 22:38:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00669 for ; Wed, 20 Jun 2001 22:38:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 22:44:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01400 for ; Wed, 20 Jun 2001 22:44:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 22:50:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02188 for ; Wed, 20 Jun 2001 22:50:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 22:56:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02275 for ; Wed, 20 Jun 2001 22:56:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 23:04:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02392 for ; Wed, 20 Jun 2001 23:04:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 23:09:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02453 for ; Wed, 20 Jun 2001 23:09:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 23:15:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02576 for ; Wed, 20 Jun 2001 23:15:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 23:22:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02624 for ; Wed, 20 Jun 2001 23:21:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 23:27:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02711 for ; Wed, 20 Jun 2001 23:27:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 23:33:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03134 for ; Wed, 20 Jun 2001 23:33:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 23:39:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03203 for ; Wed, 20 Jun 2001 23:39:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Wed Jun 20 23:45:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03403 for ; Wed, 20 Jun 2001 23:45:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 00:02:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03567 for ; Thu, 21 Jun 2001 00:02:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 00:08:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03639 for ; Thu, 21 Jun 2001 00:08:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 00:14:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03699 for ; Thu, 21 Jun 2001 00:14:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 00:20:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03758 for ; Thu, 21 Jun 2001 00:20:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 00:26:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03842 for ; Thu, 21 Jun 2001 00:26:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 00:32:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03958 for ; Thu, 21 Jun 2001 00:32:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 00:38:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04036 for ; Thu, 21 Jun 2001 00:38:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 00:44:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04104 for ; Thu, 21 Jun 2001 00:44:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 00:50:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04168 for ; Thu, 21 Jun 2001 00:50:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 00:56:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04240 for ; Thu, 21 Jun 2001 00:56:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 01:02:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04301 for ; Thu, 21 Jun 2001 01:02:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 01:08:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04646 for ; Thu, 21 Jun 2001 01:08:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 01:14:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05045 for ; Thu, 21 Jun 2001 01:14:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 01:20:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05511 for ; Thu, 21 Jun 2001 01:20:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 01:26:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06000 for ; Thu, 21 Jun 2001 01:26:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 01:32:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06458 for ; Thu, 21 Jun 2001 01:32:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 01:38:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06820 for ; Thu, 21 Jun 2001 01:38:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 01:44:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07115 for ; Thu, 21 Jun 2001 01:44:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 01:49:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07485 for ; Thu, 21 Jun 2001 01:49:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 01:55:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07888 for ; Thu, 21 Jun 2001 01:55:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 02:01:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10597 for ; Thu, 21 Jun 2001 02:01:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 02:07:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16075 for ; Thu, 21 Jun 2001 02:07:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CxEv-0006kd-00 for multi6-data@psg.com; Wed, 20 Jun 2001 22:42:49 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.16 #1) id 15CxEu-0006kX-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 22:42:49 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 20 Jun 2001 19:15:44 -0700 Received: from eagleswings [192.168.123.12] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id D76673FA34B04D029FD73E847A893EAA for plus 2 more; Wed, 20 Jun 2001 19:15:44 -0700 Reply-To: From: "Tony Hain" To: "Geoff Huston" , "Randy Bush" Cc: Subject: RE: Regionally aggregatable address space for multihoming Date: Wed, 20 Jun 2001 19:15:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.3.2.7.2.20010621081240.00c40140@kahuna.telstra.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: CEDBC7C6-8EC449F3-B2FD90B7-9B718504 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Not to extend the discussion, but this is the point I was trying to make (clearly less eloquently): > ...the starting case is that the sender has unilateral choice as > path choice to the destination, and the destination responds > to this by attempting to constrain the sender's choice ... The question is why does the destination care? Answer: because the current business models are built around optimizing inbound costs for the destination. If the business model were traffic origination based rather than termination based, the destination would not care where the originator inserted the bits. While changing business models is not a function of protocol design, existence or lack of appropriate tools may have some influence. Tony From owner-multi6@ops.ietf.org Thu Jun 21 02:07:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16080 for ; Thu, 21 Jun 2001 02:07:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 02:13:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16620 for ; Thu, 21 Jun 2001 02:13:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 02:19:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17058 for ; Thu, 21 Jun 2001 02:19:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 02:25:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17452 for ; Thu, 21 Jun 2001 02:25:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 02:31:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17943 for ; Thu, 21 Jun 2001 02:31:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 02:37:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18467 for ; Thu, 21 Jun 2001 02:37:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 02:43:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19041 for ; Thu, 21 Jun 2001 02:43:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 02:49:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19433 for ; Thu, 21 Jun 2001 02:49:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 02:55:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19935 for ; Thu, 21 Jun 2001 02:55:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 03:02:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20452 for ; Thu, 21 Jun 2001 03:01:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 03:07:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20740 for ; Thu, 21 Jun 2001 03:07:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 03:12:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20788 for ; Thu, 21 Jun 2001 03:12:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 03:19:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20867 for ; Thu, 21 Jun 2001 03:19:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 03:25:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20944 for ; Thu, 21 Jun 2001 03:25:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 03:31:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21057 for ; Thu, 21 Jun 2001 03:31:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 03:37:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21115 for ; Thu, 21 Jun 2001 03:37:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 03:43:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21165 for ; Thu, 21 Jun 2001 03:42:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 03:49:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21239 for ; Thu, 21 Jun 2001 03:48:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 03:54:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21320 for ; Thu, 21 Jun 2001 03:54:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 03:59:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21364 for ; Thu, 21 Jun 2001 03:59:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 04:06:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21422 for ; Thu, 21 Jun 2001 04:05:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 04:11:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21464 for ; Thu, 21 Jun 2001 04:11:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 05:12:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22115 for ; Thu, 21 Jun 2001 05:12:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 06:43:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22879 for ; Thu, 21 Jun 2001 06:43:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 08:59:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26569 for ; Thu, 21 Jun 2001 08:59:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 12:22:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04869 for ; Thu, 21 Jun 2001 12:22:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 12:28:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05173 for ; Thu, 21 Jun 2001 12:28:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15D5vC-000EcL-00 for multi6-data@psg.com; Thu, 21 Jun 2001 07:59:02 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15D5vB-000EcC-00 for multi6@ops.ietf.org; Thu, 21 Jun 2001 07:59:01 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 21 Jun 2001 07:58:55 -0700 Message-ID: <002201c0fa62$b14f09e0$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Brian E Carpenter" , "Paul Francis" Cc: References: <15145.9955.182872.840953@alpha-tli.procket.com><20010618173545.S5787@buddha.home.automagic.org><4.3.2.7.2.20010620100559.00c3e400@kahuna.telstra.net> <003c01c0f9ad$aefa1fa0$50030a0a@tahoenetworks.com> <3B320333.3455313D@hursley.ibm.com> Subject: Re: An idea: GxSE Date: Thu, 21 Jun 2001 07:58:55 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 21 Jun 2001 14:58:55.0398 (UTC) FILETIME=[B1419C60:01C0FA62] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > 1. Somebody asked how to allocate the SK prefix. This is easy enough to > do in several ways, but a painless way is to use the site's RFC 3056 > prefix, at least for the first ten years or so of allocations. This works too. > > 2. Paul says that sites would have to renumber when they merge. I'm not > convinced that is a requirement. If two sites with different SK prefixes > merge, it seems to me they can simply route between those two prefixes > internally. Even if renumbering turns out to be a good idea in the long > term, it can be done piecewise - no flag day needed. The problem is not internal routing, but external. If you continue to use different GR prefixes for the two merged halves after merge, then you don't have to do anything...just leak internal prefixes into the opposite half as you suggest---so at least you avoid the flag day. If you do want both halves to use the same GR prefixes, which sooner or later you might, then the site border routers need to know how to translate incoming packets. If both halves use the same SLA's, then the only way the border router can know how to do that is by keeping a list of individual hosts and thier prefixes. Still kindof doable---the site border router can get a dump from DNS or something---but not what you'd want. So eventually you do have to do some renumbering when sites merge. But at least this is not at the whim of your ISP... > > Apart from that I am worried about the amount of complexity you are asking > hosts to implement. For some types of host (e.g. handhelds) this will be an > issue. I think there could be a simplified version of GxSE lurking in there > somewhere. > There is a tradeoff here. If you did GSxE, then you might be able to avoid some of the existing multiple addresses complexity in the handheld...i.e., one SK address instead of several global addresses. Obviously too early to know the trade-offs. PF From owner-multi6@ops.ietf.org Thu Jun 21 12:30:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05268 for ; Thu, 21 Jun 2001 12:29:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 12:30:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05275 for ; Thu, 21 Jun 2001 12:30:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15D5Qi-000E3p-00 for multi6-data@psg.com; Thu, 21 Jun 2001 07:27:32 -0700 Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by psg.com with esmtp (Exim 3.16 #1) id 15D5Qh-000E3Y-00 for multi6@ops.ietf.org; Thu, 21 Jun 2001 07:27:31 -0700 Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id HAA40050; Thu, 21 Jun 2001 07:26:55 -0700 Received: from hursley.ibm.com (lig32-225-115-69.us.lig-dial.ibm.com [32.225.115.69]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA18662; Thu, 21 Jun 2001 07:26:58 -0700 Message-ID: <3B320333.3455313D@hursley.ibm.com> Date: Thu, 21 Jun 2001 09:22:43 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Paul Francis CC: multi6@ops.ietf.org Subject: Re: An idea: GxSE References: <15145.9955.182872.840953@alpha-tli.procket.com><20010618173545.S5787@buddha.home.automagic.org><4.3.2.7.2.20010620100559.00c3e400@kahuna.telstra.net> <003c01c0f9ad$aefa1fa0$50030a0a@tahoenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Another couple of points: 1. Somebody asked how to allocate the SK prefix. This is easy enough to do in several ways, but a painless way is to use the site's RFC 3056 prefix, at least for the first ten years or so of allocations. 2. Paul says that sites would have to renumber when they merge. I'm not convinced that is a requirement. If two sites with different SK prefixes merge, it seems to me they can simply route between those two prefixes internally. Even if renumbering turns out to be a good idea in the long term, it can be done piecewise - no flag day needed. Apart from that I am worried about the amount of complexity you are asking hosts to implement. For some types of host (e.g. handhelds) this will be an issue. I think there could be a simplified version of GxSE lurking in there somewhere. Brian From owner-multi6@ops.ietf.org Thu Jun 21 12:30:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05321 for ; Thu, 21 Jun 2001 12:30:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 12:30:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05376 for ; Thu, 21 Jun 2001 12:30:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 12:35:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05645 for ; Thu, 21 Jun 2001 12:35:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 12:41:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05953 for ; Thu, 21 Jun 2001 12:41:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 12:46:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06176 for ; Thu, 21 Jun 2001 12:46:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 12:52:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06413 for ; Thu, 21 Jun 2001 12:52:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 12:58:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06839 for ; Thu, 21 Jun 2001 12:58:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 12:59:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06890 for ; Thu, 21 Jun 2001 12:59:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 13:05:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07305 for ; Thu, 21 Jun 2001 13:05:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 13:12:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07739 for ; Thu, 21 Jun 2001 13:12:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 13:18:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08030 for ; Thu, 21 Jun 2001 13:18:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 13:24:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08458 for ; Thu, 21 Jun 2001 13:24:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15D7v9-000GcN-00 for multi6-data@psg.com; Thu, 21 Jun 2001 10:07:07 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.16 #1) id 15D7v8-000GcG-00 for multi6@ops.ietf.org; Thu, 21 Jun 2001 10:07:06 -0700 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09139; Thu, 21 Jun 2001 11:07:02 -0600 (MDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id KAA00314; Thu, 21 Jun 2001 10:08:17 -0700 (PDT) Received: from locked (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5LH6tG208433; Thu, 21 Jun 2001 10:06:55 -0700 (PDT) Message-Id: <200106211706.f5LH6tG208433@jurassic.eng.sun.com> Date: Thu, 21 Jun 2001 10:05:38 -0700 (PDT) From: Mohan Parthasarathy Reply-To: Mohan Parthasarathy Subject: Re: An idea: GxSE To: Mohan.Parthasarathy@eng.sun.com, taz@tazlore.com Cc: paul@francis.com, multi6@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vCRdJShInn4yeWNnZxVlhQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-multi6@ops.ietf.org Precedence: bulk > > > > When you are moving around, you are getting new prefixes and the old > > prefixes will not be valid after sometime. (The difference between > > this and mobility is that the old prefix is considered to be valid > > in mobility) > > You're not moving around a lot. Again, this isn't mobility. This is > often the result of a circuit or router going down in the case of > multihoming. In thse situations, the prefix is never invalidated, it's > just useless for a while. > Interestingly i could not find the work "renumbering" anywhere in the charter. I am assuming it should be understood implicitly. So, there are two cases 1) Site is multihomed and one of the links to the ISP is broken and how we get around this without breaking any connections. 2) Site is multihomed and there is a long running e.g. TCP connection which needs to survive in the case of renumbering. So, we are addressing (1) in this WG. Hence, the use of word renumbering is confusing to me. Could somebody clarify this ? thanks -mohan From owner-multi6@ops.ietf.org Thu Jun 21 13:24:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08465 for ; Thu, 21 Jun 2001 13:24:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 13:30:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08861 for ; Thu, 21 Jun 2001 13:30:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 13:35:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09218 for ; Thu, 21 Jun 2001 13:35:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 13:41:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09536 for ; Thu, 21 Jun 2001 13:41:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 13:47:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09889 for ; Thu, 21 Jun 2001 13:47:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 13:53:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10225 for ; Thu, 21 Jun 2001 13:53:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 13:59:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10579 for ; Thu, 21 Jun 2001 13:59:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 14:08:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11324 for ; Thu, 21 Jun 2001 14:08:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 14:14:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11663 for ; Thu, 21 Jun 2001 14:14:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 14:20:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12233 for ; Thu, 21 Jun 2001 14:20:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15D939-000Hnv-00 for multi6-data@psg.com; Thu, 21 Jun 2001 11:19:27 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15D938-000Hnp-00 for multi6@ops.ietf.org; Thu, 21 Jun 2001 11:19:26 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 21 Jun 2001 11:19:25 -0700 Message-ID: <004401c0fa7e$b3bb1720$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Mohan Parthasarathy" , Cc: , References: <200106211706.f5LH6tG208433@jurassic.eng.sun.com> Subject: Re: An idea: GxSE Date: Thu, 21 Jun 2001 11:19:25 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 21 Jun 2001 18:19:25.0331 (UTC) FILETIME=[B3A7B630:01C0FA7E] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > 1) Site is multihomed and one of the links to the ISP is broken and > how we get around this without breaking any connections. > > 2) Site is multihomed and there is a long running e.g. TCP connection > which needs to survive in the case of renumbering. > > So, we are addressing (1) in this WG. Hence, the use of word renumbering > is confusing to me. Could somebody clarify this ? > I think, broadly stated, the goal of the wg is to have the same multihoming functionality with IPv6 as we have with IPv4, but done in a scalable way. But multi6 is producing a requirements document that will clarify things. With IPv4 multihoming today (ignoring the NAT case), case 1 works, so presumably we want this functionality with IPv6. Even so, I think in most cases losing a connection because an ISP went down would be acceptable, as long as new connections indeed chose the other ISP. Case 2 is less clear, because we really don't have renumbering with IPv4. I'd argue myself that we should not go out of our way to design for case 2, for the reasons I said before (it is relatively rare, and you should in most cases be able to overlap the old and new prefixes so that most long-term connections will have naturally terminated on their own). PF From owner-multi6@ops.ietf.org Thu Jun 21 14:20:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12242 for ; Thu, 21 Jun 2001 14:20:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 14:26:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12607 for ; Thu, 21 Jun 2001 14:26:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 14:33:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13040 for ; Thu, 21 Jun 2001 14:33:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 14:40:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13531 for ; Thu, 21 Jun 2001 14:40:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 14:49:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13959 for ; Thu, 21 Jun 2001 14:49:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 14:55:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14096 for ; Thu, 21 Jun 2001 14:55:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15D9J6-000I4s-00 for multi6-data@psg.com; Thu, 21 Jun 2001 11:35:56 -0700 Received: from garlic.amaranth.net ([216.235.243.195]) by psg.com with esmtp (Exim 3.16 #1) id 15D9J5-000I4h-00 for multi6@ops.ietf.org; Thu, 21 Jun 2001 11:35:55 -0700 Received: from yarrow.senie.com (dialup-63.214.83.186.Dial1.Boston1.Level3.net [63.214.83.186]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f5LIZTl03935 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Thu, 21 Jun 2001 14:35:42 -0400 Message-Id: <5.1.0.14.2.20010621142920.03d020d0@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Jun 2001 14:35:26 -0400 To: "Paul Francis" From: Daniel Senie Subject: Re: An idea: GxSE Cc: In-Reply-To: <004401c0fa7e$b3bb1720$50030a0a@tahoenetworks.com> References: <200106211706.f5LH6tG208433@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 02:19 PM 6/21/01, Paul Francis wrote: > > > > 1) Site is multihomed and one of the links to the ISP is broken and > > how we get around this without breaking any connections. > > > > 2) Site is multihomed and there is a long running e.g. TCP connection > > which needs to survive in the case of renumbering. > > > > So, we are addressing (1) in this WG. Hence, the use of word renumbering > > is confusing to me. Could somebody clarify this ? > > > >I think, broadly stated, the goal of the wg is to have the same multihoming >functionality with IPv6 as we have with IPv4, but done in a scalable way. >But multi6 is producing a requirements document that will clarify things. > >With IPv4 multihoming today (ignoring the NAT case), case 1 works, so >presumably we want this functionality with IPv6. Even so, I think in most >cases losing a connection because an ISP went down would be acceptable, as >long as new connections indeed chose the other ISP. In the present Internet, the sessions already break when a link dies. The backbone convergence is taking too long for applications in many cases, from my observations. So, application writers either have to build in auto-reconnect logic, or their apps are going to have problems. So, I don't know that there's much problem with the new sessions starting with different addresses, provided end systems are told in some way that an upstream link died (i.e. they have to know to use the other link). ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-multi6@ops.ietf.org Thu Jun 21 14:55:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14104 for ; Thu, 21 Jun 2001 14:55:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 15:01:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14284 for ; Thu, 21 Jun 2001 15:01:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 15:07:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14426 for ; Thu, 21 Jun 2001 15:07:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 15:14:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14736 for ; Thu, 21 Jun 2001 15:14:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 15:19:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14945 for ; Thu, 21 Jun 2001 15:19:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 15:24:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15154 for ; Thu, 21 Jun 2001 15:24:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15D9eF-000IR1-00 for multi6-data@psg.com; Thu, 21 Jun 2001 11:57:47 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.16 #1) id 15D9eE-000IQv-00 for multi6@ops.ietf.org; Thu, 21 Jun 2001 11:57:46 -0700 Received: (qmail 30721 invoked by uid 100); 21 Jun 2001 18:57:33 -0000 Date: Thu, 21 Jun 2001 14:57:32 -0400 From: Joe Abley To: Daniel Senie Cc: Paul Francis , multi6@ops.ietf.org Subject: Re: An idea: GxSE Message-ID: <20010621145732.F13514@buddha.home.automagic.org> References: <200106211706.f5LH6tG208433@jurassic.eng.sun.com> <004401c0fa7e$b3bb1720$50030a0a@tahoenetworks.com> <5.1.0.14.2.20010621142920.03d020d0@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.2.20010621142920.03d020d0@mail.amaranth.net>; from dts@senie.com on Thu, Jun 21, 2001 at 02:35:26PM -0400 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, Jun 21, 2001 at 02:35:26PM -0400, Daniel Senie wrote: > At 02:19 PM 6/21/01, Paul Francis wrote: > > > > > > 1) Site is multihomed and one of the links to the ISP is broken and > > > how we get around this without breaking any connections. > > > > > > 2) Site is multihomed and there is a long running e.g. TCP connection > > > which needs to survive in the case of renumbering. > > > > > > So, we are addressing (1) in this WG. Hence, the use of word renumbering > > > is confusing to me. Could somebody clarify this ? > > > > > > >I think, broadly stated, the goal of the wg is to have the same multihoming > >functionality with IPv6 as we have with IPv4, but done in a scalable way. > >But multi6 is producing a requirements document that will clarify things. > > > >With IPv4 multihoming today (ignoring the NAT case), case 1 works, so > >presumably we want this functionality with IPv6. Even so, I think in most > >cases losing a connection because an ISP went down would be acceptable, as > >long as new connections indeed chose the other ISP. > > In the present Internet, the sessions already break when a link dies. The > backbone convergence is taking too long for applications in many cases, > from my observations. So, application writers either have to build in > auto-reconnect logic, or their apps are going to have problems. This is not my experience. TCP session stability around a re-homing event (i.e. the session recovers, and does not fail) is common, even when end-points are relatively remote (my experience is between New Zealand and Europe). Remember that full convergence across the internet is not necessary for packets to continue to reach their proscribed destinations; ASes route with default, withdrawn prefixes are covered by aggregates, etc. > So, I don't know that there's much problem with the new sessions starting > with different addresses, provided end systems are told in some way that an > upstream link died (i.e. they have to know to use the other link). The problem is that the current multi-homing strategies in use with v4 provide for session stability, and we are trying (as far as is possible) to encapsulate the capabilities of the current architecture in the requirements for the new one. Joe From owner-multi6@ops.ietf.org Thu Jun 21 15:25:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15180 for ; Thu, 21 Jun 2001 15:25:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 15:30:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15274 for ; Thu, 21 Jun 2001 15:30:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 15:36:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15436 for ; Thu, 21 Jun 2001 15:36:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 15:41:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15689 for ; Thu, 21 Jun 2001 15:41:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DALF-000JES-00 for multi6-data@psg.com; Thu, 21 Jun 2001 12:42:13 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15DALE-000JEM-00 for multi6@ops.ietf.org; Thu, 21 Jun 2001 12:42:12 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id OAA08704; Thu, 21 Jun 2001 14:42:23 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Thu, 21 Jun 2001 14:42:23 -0500 (CDT) From: "Jon (Taz) Mischo" To: Joe Abley cc: Daniel Senie , Paul Francis , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <20010621152836.H13514@buddha.home.automagic.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk BTW, folks...I think some of this might be of interest to irtf-rr, since we're really talking about the important issues related to multihomed routing. There are folks on irtf-rr that would have some great stats for us, and others with other input. On Thu, 21 Jun 2001, Joe Abley wrote: > Date: Thu, 21 Jun 2001 15:28:36 -0400 > From: Joe Abley > To: Daniel Senie > Cc: Paul Francis , multi6@ops.ietf.org > Subject: Re: An idea: GxSE > > On Thu, Jun 21, 2001 at 03:17:37PM -0400, Daniel Senie wrote: > > At 02:57 PM 6/21/01, Joe Abley wrote: > > >On Thu, Jun 21, 2001 at 02:35:26PM -0400, Daniel Senie wrote: > > > > In the present Internet, the sessions already break when a link dies. The > > > > backbone convergence is taking too long for applications in many cases, > > > > from my observations. So, application writers either have to build in > > > > auto-reconnect logic, or their apps are going to have problems. > > > > > >This is not my experience. TCP session stability around a re-homing > > >event (i.e. the session recovers, and does not fail) is common, even > > >when end-points are relatively remote (my experience is between New > > >Zealand and Europe). > > > > It is my experience with a variety of access services around New England. > > > > >Remember that full convergence across the internet is not necessary > > >for packets to continue to reach their proscribed destinations; ASes > > >route with default, withdrawn prefixes are covered by aggregates, > > >etc. > > > > We see the traffic die at the first default-free router. Sessions usually > > time out while the BGP withdrawals are still flapping around. > > I'd be interested to know exactly what you were advertising, and > what failure scenarios cause TCP sessions reliably to die; sounds > like it might be worth comparing it to what we did in 4768, since > our experience is interestingly different. If you would like to > follow this up, please feel free to mail me privately (we can > summarise if there are relevant conclusions). > > One question you might ask yourself, however, is whether there might > have been re-homing events elsewhere between your network and the > destination that TCP sessions might have survived without you knowing. > Can you definitely conclude that TCP sessions invariably collapsed? > Or is there a chance that there were other re-homing scenarios during > which TCP sessions survived without you noticing? > > > I understand that, but I disagree that the present mechanism works in the > > real world, so the question is whether it's a worthwhile requirement going > > forward. You've seen good results in the face of rerouting, I've seen very > > bad results. Two data points don't tell us a lot. The question should be > > asked, though, as to whether the present mechanism is working and thus > > worth keeping, before engraving it in stone for IPv6. > > > Joe > -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Thu Jun 21 15:42:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15713 for ; Thu, 21 Jun 2001 15:42:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DA88-000Ixq-00 for multi6-data@psg.com; Thu, 21 Jun 2001 12:28:40 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.16 #1) id 15DA86-000IxW-00 for multi6@ops.ietf.org; Thu, 21 Jun 2001 12:28:38 -0700 Received: (qmail 17769 invoked by uid 100); 21 Jun 2001 19:28:36 -0000 Date: Thu, 21 Jun 2001 15:28:36 -0400 From: Joe Abley To: Daniel Senie Cc: Paul Francis , multi6@ops.ietf.org Subject: Re: An idea: GxSE Message-ID: <20010621152836.H13514@buddha.home.automagic.org> References: <5.1.0.14.2.20010621142920.03d020d0@mail.amaranth.net> <200106211706.f5LH6tG208433@jurassic.eng.sun.com> <004401c0fa7e$b3bb1720$50030a0a@tahoenetworks.com> <5.1.0.14.2.20010621142920.03d020d0@mail.amaranth.net> <20010621145732.F13514@buddha.home.automagic.org> <5.1.0.14.2.20010621151424.00a1f8a0@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.2.20010621151424.00a1f8a0@mail.amaranth.net>; from dts@senie.com on Thu, Jun 21, 2001 at 03:17:37PM -0400 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, Jun 21, 2001 at 03:17:37PM -0400, Daniel Senie wrote: > At 02:57 PM 6/21/01, Joe Abley wrote: > >On Thu, Jun 21, 2001 at 02:35:26PM -0400, Daniel Senie wrote: > > > In the present Internet, the sessions already break when a link dies. The > > > backbone convergence is taking too long for applications in many cases, > > > from my observations. So, application writers either have to build in > > > auto-reconnect logic, or their apps are going to have problems. > > > >This is not my experience. TCP session stability around a re-homing > >event (i.e. the session recovers, and does not fail) is common, even > >when end-points are relatively remote (my experience is between New > >Zealand and Europe). > > It is my experience with a variety of access services around New England. > > >Remember that full convergence across the internet is not necessary > >for packets to continue to reach their proscribed destinations; ASes > >route with default, withdrawn prefixes are covered by aggregates, > >etc. > > We see the traffic die at the first default-free router. Sessions usually > time out while the BGP withdrawals are still flapping around. I'd be interested to know exactly what you were advertising, and what failure scenarios cause TCP sessions reliably to die; sounds like it might be worth comparing it to what we did in 4768, since our experience is interestingly different. If you would like to follow this up, please feel free to mail me privately (we can summarise if there are relevant conclusions). One question you might ask yourself, however, is whether there might have been re-homing events elsewhere between your network and the destination that TCP sessions might have survived without you knowing. Can you definitely conclude that TCP sessions invariably collapsed? Or is there a chance that there were other re-homing scenarios during which TCP sessions survived without you noticing? > I understand that, but I disagree that the present mechanism works in the > real world, so the question is whether it's a worthwhile requirement going > forward. You've seen good results in the face of rerouting, I've seen very > bad results. Two data points don't tell us a lot. The question should be > asked, though, as to whether the present mechanism is working and thus > worth keeping, before engraving it in stone for IPv6. Joe From owner-multi6@ops.ietf.org Thu Jun 21 15:44:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15753 for ; Thu, 21 Jun 2001 15:44:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 15:44:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15764 for ; Thu, 21 Jun 2001 15:44:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DA3n-000Irj-00 for multi6-data@psg.com; Thu, 21 Jun 2001 12:24:11 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15DA3m-000Ird-00 for multi6@ops.ietf.org; Thu, 21 Jun 2001 12:24:10 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 21 Jun 2001 12:24:09 -0700 Message-ID: <0c1901c0fa87$bf20ca20$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Joe Abley" , "Daniel Senie" Cc: References: <5.1.0.14.2.20010621142920.03d020d0@mail.amaranth.net> <200106211706.f5LH6tG208433@jurassic.eng.sun.com> <004401c0fa7e$b3bb1720$50030a0a@tahoenetworks.com> <5.1.0.14.2.20010621142920.03d020d0@mail.amaranth.net> <5.1.0.14.2.20010621151424.00a1f8a0@mail.amaranth.net> Subject: Re: An idea: GxSE Date: Thu, 21 Jun 2001 12:24:09 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 21 Jun 2001 19:24:09.0945 (UTC) FILETIME=[BF10C490:01C0FA87] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > I understand that, but I disagree that the present mechanism works in the > real world, so the question is whether it's a worthwhile requirement going > forward. You've seen good results in the face of rerouting, I've seen very > bad results. Two data points don't tell us a lot. The question should be > asked, though, as to whether the present mechanism is working and thus > worth keeping, before engraving it in stone for IPv6. Are you talking about route flapping and BGP? If so, this is orthogonal to the multi-homing problem (though not unaffected by it, if we can reduce routing table size). Are you multihomed? Maybe if you were, then you could avoid this problem by re-routing your traffic :-) PF From owner-multi6@ops.ietf.org Thu Jun 21 15:50:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15991 for ; Thu, 21 Jun 2001 15:50:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15D9xg-000IlZ-00 for multi6-data@psg.com; Thu, 21 Jun 2001 12:17:52 -0700 Received: from garlic.amaranth.net ([216.235.243.195]) by psg.com with esmtp (Exim 3.16 #1) id 15D9xf-000IlT-00 for multi6@ops.ietf.org; Thu, 21 Jun 2001 12:17:51 -0700 Received: from yarrow.senie.com (dialup-63.214.83.186.Dial1.Boston1.Level3.net [63.214.83.186]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f5LJHel06885 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Thu, 21 Jun 2001 15:17:43 -0400 Message-Id: <5.1.0.14.2.20010621151424.00a1f8a0@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Jun 2001 15:17:37 -0400 To: Joe Abley From: Daniel Senie Subject: Re: An idea: GxSE Cc: Paul Francis , multi6@ops.ietf.org In-Reply-To: <20010621145732.F13514@buddha.home.automagic.org> References: <5.1.0.14.2.20010621142920.03d020d0@mail.amaranth.net> <200106211706.f5LH6tG208433@jurassic.eng.sun.com> <004401c0fa7e$b3bb1720$50030a0a@tahoenetworks.com> <5.1.0.14.2.20010621142920.03d020d0@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 02:57 PM 6/21/01, Joe Abley wrote: >On Thu, Jun 21, 2001 at 02:35:26PM -0400, Daniel Senie wrote: > > At 02:19 PM 6/21/01, Paul Francis wrote: > > > > > > > > 1) Site is multihomed and one of the links to the ISP is broken and > > > > how we get around this without breaking any connections. > > > > > > > > 2) Site is multihomed and there is a long running e.g. TCP connection > > > > which needs to survive in the case of renumbering. > > > > > > > > So, we are addressing (1) in this WG. Hence, the use of word > renumbering > > > > is confusing to me. Could somebody clarify this ? > > > > > > > > > >I think, broadly stated, the goal of the wg is to have the same > multihoming > > >functionality with IPv6 as we have with IPv4, but done in a scalable way. > > >But multi6 is producing a requirements document that will clarify things. > > > > > >With IPv4 multihoming today (ignoring the NAT case), case 1 works, so > > >presumably we want this functionality with IPv6. Even so, I think in most > > >cases losing a connection because an ISP went down would be acceptable, as > > >long as new connections indeed chose the other ISP. > > > > In the present Internet, the sessions already break when a link dies. The > > backbone convergence is taking too long for applications in many cases, > > from my observations. So, application writers either have to build in > > auto-reconnect logic, or their apps are going to have problems. > >This is not my experience. TCP session stability around a re-homing >event (i.e. the session recovers, and does not fail) is common, even >when end-points are relatively remote (my experience is between New >Zealand and Europe). It is my experience with a variety of access services around New England. >Remember that full convergence across the internet is not necessary >for packets to continue to reach their proscribed destinations; ASes >route with default, withdrawn prefixes are covered by aggregates, >etc. We see the traffic die at the first default-free router. Sessions usually time out while the BGP withdrawals are still flapping around. > > So, I don't know that there's much problem with the new sessions starting > > with different addresses, provided end systems are told in some way > that an > > upstream link died (i.e. they have to know to use the other link). > >The problem is that the current multi-homing strategies in use with v4 >provide for session stability, and we are trying (as far as is possible) >to encapsulate the capabilities of the current architecture in the >requirements for the new one. I understand that, but I disagree that the present mechanism works in the real world, so the question is whether it's a worthwhile requirement going forward. You've seen good results in the face of rerouting, I've seen very bad results. Two data points don't tell us a lot. The question should be asked, though, as to whether the present mechanism is working and thus worth keeping, before engraving it in stone for IPv6. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-multi6@ops.ietf.org Thu Jun 21 15:51:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16018 for ; Thu, 21 Jun 2001 15:51:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DAJh-000JCO-00 for multi6-data@psg.com; Thu, 21 Jun 2001 12:40:37 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15DAJg-000JCI-00 for multi6@ops.ietf.org; Thu, 21 Jun 2001 12:40:36 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id OAA08698; Thu, 21 Jun 2001 14:40:42 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Thu, 21 Jun 2001 14:40:42 -0500 (CDT) From: "Jon (Taz) Mischo" To: Daniel Senie cc: Joe Abley , Paul Francis , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <5.1.0.14.2.20010621151424.00a1f8a0@mail.amaranth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 21 Jun 2001, Daniel Senie wrote: > Date: Thu, 21 Jun 2001 15:17:37 -0400 > From: Daniel Senie > To: Joe Abley > Cc: Paul Francis , multi6@ops.ietf.org > Subject: Re: An idea: GxSE > > At 02:57 PM 6/21/01, Joe Abley wrote: > >On Thu, Jun 21, 2001 at 02:35:26PM -0400, Daniel Senie wrote: > > > At 02:19 PM 6/21/01, Paul Francis wrote: > > > > > > > > > > 1) Site is multihomed and one of the links to the ISP is broken and > > > > > how we get around this without breaking any connections. > > > > > > > > > > 2) Site is multihomed and there is a long running e.g. TCP connection > > > > > which needs to survive in the case of renumbering. > > > > > > > > > > So, we are addressing (1) in this WG. Hence, the use of word > > renumbering > > > > > is confusing to me. Could somebody clarify this ? > > > > > > > > > > > > >I think, broadly stated, the goal of the wg is to have the same > > multihoming > > > >functionality with IPv6 as we have with IPv4, but done in a scalable way. > > > >But multi6 is producing a requirements document that will clarify things. > > > > > > > >With IPv4 multihoming today (ignoring the NAT case), case 1 works, so > > > >presumably we want this functionality with IPv6. Even so, I think in most > > > >cases losing a connection because an ISP went down would be acceptable, as > > > >long as new connections indeed chose the other ISP. > > > > > > In the present Internet, the sessions already break when a link dies. The > > > backbone convergence is taking too long for applications in many cases, > > > from my observations. So, application writers either have to build in > > > auto-reconnect logic, or their apps are going to have problems. > > > >This is not my experience. TCP session stability around a re-homing > >event (i.e. the session recovers, and does not fail) is common, even > >when end-points are relatively remote (my experience is between New > >Zealand and Europe). > > It is my experience with a variety of access services around New England. If this is such a big deal, use SCTP. That's what it's there for. If you really care how a session survives network topogoly changes and BGP flap, use SCTP, as it's designed to handle this. > >Remember that full convergence across the internet is not necessary > >for packets to continue to reach their proscribed destinations; ASes > >route with default, withdrawn prefixes are covered by aggregates, > >etc. > > We see the traffic die at the first default-free router. Sessions usually > time out while the BGP withdrawals are still flapping around. > > > > > So, I don't know that there's much problem with the new sessions starting > > > with different addresses, provided end systems are told in some way > > that an > > > upstream link died (i.e. they have to know to use the other link). > > > >The problem is that the current multi-homing strategies in use with v4 > >provide for session stability, and we are trying (as far as is possible) > >to encapsulate the capabilities of the current architecture in the > >requirements for the new one. > > I understand that, but I disagree that the present mechanism works in the > real world, so the question is whether it's a worthwhile requirement going > forward. You've seen good results in the face of rerouting, I've seen very > bad results. Two data points don't tell us a lot. The question should be > asked, though, as to whether the present mechanism is working and thus > worth keeping, before engraving it in stone for IPv6. As a whole, I've seen a lot of bad convergence. Sometime convergence is fast, but that's pretty rare with BGP. Your individual mileage WILL vary, depending on where the network is broken, and how aggregation is done behind it. Sometimes it's good, sometimes it's bad. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Thu Jun 21 15:51:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16025 for ; Thu, 21 Jun 2001 15:51:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 15:57:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16138 for ; Thu, 21 Jun 2001 15:57:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 16:02:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16266 for ; Thu, 21 Jun 2001 16:02:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 16:07:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16426 for ; Thu, 21 Jun 2001 16:07:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 16:13:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16564 for ; Thu, 21 Jun 2001 16:13:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 16:19:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16669 for ; Thu, 21 Jun 2001 16:19:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 16:25:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16788 for ; Thu, 21 Jun 2001 16:25:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 16:31:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16963 for ; Thu, 21 Jun 2001 16:31:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 16:43:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17313 for ; Thu, 21 Jun 2001 16:43:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 16:48:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17431 for ; Thu, 21 Jun 2001 16:48:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 16:56:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17646 for ; Thu, 21 Jun 2001 16:56:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 17:02:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17753 for ; Thu, 21 Jun 2001 17:02:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 17:07:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17849 for ; Thu, 21 Jun 2001 17:07:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 17:13:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18004 for ; Thu, 21 Jun 2001 17:13:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 17:19:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18068 for ; Thu, 21 Jun 2001 17:19:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 17:25:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18199 for ; Thu, 21 Jun 2001 17:25:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 17:31:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18344 for ; Thu, 21 Jun 2001 17:31:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 17:37:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18450 for ; Thu, 21 Jun 2001 17:37:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 17:43:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18567 for ; Thu, 21 Jun 2001 17:43:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 17:51:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18704 for ; Thu, 21 Jun 2001 17:51:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 18:51:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19551 for ; Thu, 21 Jun 2001 18:51:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 20:23:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21453 for ; Thu, 21 Jun 2001 20:23:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 20:24:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21505 for ; Thu, 21 Jun 2001 20:24:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 20:30:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21720 for ; Thu, 21 Jun 2001 20:30:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 20:36:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21924 for ; Thu, 21 Jun 2001 20:36:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 20:42:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22117 for ; Thu, 21 Jun 2001 20:42:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 20:49:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22289 for ; Thu, 21 Jun 2001 20:49:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 20:56:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22528 for ; Thu, 21 Jun 2001 20:56:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 21:02:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22721 for ; Thu, 21 Jun 2001 21:02:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 21:08:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22854 for ; Thu, 21 Jun 2001 21:08:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 21:14:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22934 for ; Thu, 21 Jun 2001 21:14:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 21:20:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23065 for ; Thu, 21 Jun 2001 21:20:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 21:27:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23138 for ; Thu, 21 Jun 2001 21:27:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 21:33:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23349 for ; Thu, 21 Jun 2001 21:33:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 21:39:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24355 for ; Thu, 21 Jun 2001 21:39:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 21:44:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24491 for ; Thu, 21 Jun 2001 21:44:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 21:51:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24567 for ; Thu, 21 Jun 2001 21:51:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 21:57:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24608 for ; Thu, 21 Jun 2001 21:57:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 22:03:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24742 for ; Thu, 21 Jun 2001 22:03:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 22:08:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24807 for ; Thu, 21 Jun 2001 22:08:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 22:16:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24939 for ; Thu, 21 Jun 2001 22:16:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 22:21:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25101 for ; Thu, 21 Jun 2001 22:21:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 22:27:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25206 for ; Thu, 21 Jun 2001 22:27:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 23:28:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26842 for ; Thu, 21 Jun 2001 23:28:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 23:40:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27329 for ; Thu, 21 Jun 2001 23:40:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 23:47:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27434 for ; Thu, 21 Jun 2001 23:47:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 23:52:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27472 for ; Thu, 21 Jun 2001 23:52:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Thu Jun 21 23:57:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27515 for ; Thu, 21 Jun 2001 23:57:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 00:04:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27585 for ; Fri, 22 Jun 2001 00:04:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 00:11:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27628 for ; Fri, 22 Jun 2001 00:11:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 00:18:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27664 for ; Fri, 22 Jun 2001 00:18:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 00:25:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27940 for ; Fri, 22 Jun 2001 00:25:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 00:32:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28013 for ; Fri, 22 Jun 2001 00:32:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 00:39:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28052 for ; Fri, 22 Jun 2001 00:39:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 00:45:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28119 for ; Fri, 22 Jun 2001 00:45:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 00:51:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28145 for ; Fri, 22 Jun 2001 00:51:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 00:57:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28210 for ; Fri, 22 Jun 2001 00:57:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 01:03:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28365 for ; Fri, 22 Jun 2001 01:03:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 01:12:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28859 for ; Fri, 22 Jun 2001 01:12:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 01:19:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29355 for ; Fri, 22 Jun 2001 01:19:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 01:26:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29816 for ; Fri, 22 Jun 2001 01:26:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 01:32:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00222 for ; Fri, 22 Jun 2001 01:32:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 01:38:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00541 for ; Fri, 22 Jun 2001 01:38:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 01:44:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00820 for ; Fri, 22 Jun 2001 01:44:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 01:49:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01157 for ; Fri, 22 Jun 2001 01:49:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 01:55:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01523 for ; Fri, 22 Jun 2001 01:55:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 02:01:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03606 for ; Fri, 22 Jun 2001 02:01:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 02:07:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA09604 for ; Fri, 22 Jun 2001 02:07:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 02:13:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA09943 for ; Fri, 22 Jun 2001 02:13:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 02:19:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10421 for ; Fri, 22 Jun 2001 02:19:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 02:25:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10732 for ; Fri, 22 Jun 2001 02:25:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 02:30:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11184 for ; Fri, 22 Jun 2001 02:30:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 02:36:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11614 for ; Fri, 22 Jun 2001 02:36:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 02:41:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12065 for ; Fri, 22 Jun 2001 02:41:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 02:47:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12452 for ; Fri, 22 Jun 2001 02:47:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 03:48:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14252 for ; Fri, 22 Jun 2001 03:48:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 05:18:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14960 for ; Fri, 22 Jun 2001 05:18:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 07:34:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16800 for ; Fri, 22 Jun 2001 07:34:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DNdV-000887-00 for multi6-data@psg.com; Fri, 22 Jun 2001 02:53:57 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.16 #1) id 15DNdU-000881-00 for multi6@ops.ietf.org; Fri, 22 Jun 2001 02:53:56 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20522; Fri, 22 Jun 2001 03:53:53 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f5M9rq707492; Fri, 22 Jun 2001 11:53:52 +0200 (MET DST) Date: Fri, 22 Jun 2001 11:53:37 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: An idea: GxSE To: Paul Francis Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <003c01c0f9ad$aefa1fa0$50030a0a@tahoenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > Every host knows at least one (and typically only one) address for itself, > called the self-known address (SK address). The SK address may or may not > be globally routable, but must be globally unique. I think that today there are distributed (multi-party) applications that depend on an application being able to extract a globally routable IP address of the box (so that it can be passed to peers etc). It would be good to run the idea of apps not knowing their GR addresses passed folks with better application knowledge. It the applications need to know the GR addresses but the host itself doesn't know them then it seems like you need a way to map from SK to GR addresses. > The list of addresses (GR and SK) is conveyed to partner hosts by an IPv6 > extension header---the address-list extension. This header is typically > added by the site border router as the packet exits the site. (It could Having intermediate nodes change the length of the packet does cause some issues with path MTU discovery. That's why encapsulation is normally used (e.g. in mobile IP) to deal with this. > Pseudo-header checksums and IPsec would I suppose be based on the SK address > only (not the GR addresses). It would be good to look at the effects of bit errors in the source GR address. With no IPv6 header checksum and the GR address not being part of the pseudo-header checksum means that it is unprotected. (Perhaps having a checksum on the address-list extension can catch this.) Erik From owner-multi6@ops.ietf.org Fri Jun 22 07:35:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16820 for ; Fri, 22 Jun 2001 07:35:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 07:42:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17035 for ; Fri, 22 Jun 2001 07:42:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 07:48:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17190 for ; Fri, 22 Jun 2001 07:48:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 07:54:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17299 for ; Fri, 22 Jun 2001 07:54:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 08:00:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17507 for ; Fri, 22 Jun 2001 08:00:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 08:06:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17683 for ; Fri, 22 Jun 2001 08:06:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 08:13:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18009 for ; Fri, 22 Jun 2001 08:13:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 08:19:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18199 for ; Fri, 22 Jun 2001 08:19:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 08:25:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18378 for ; Fri, 22 Jun 2001 08:25:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 08:32:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18628 for ; Fri, 22 Jun 2001 08:32:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 08:38:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18875 for ; Fri, 22 Jun 2001 08:38:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 08:44:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19122 for ; Fri, 22 Jun 2001 08:44:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 08:50:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19355 for ; Fri, 22 Jun 2001 08:50:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 08:56:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19534 for ; Fri, 22 Jun 2001 08:56:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 09:01:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19753 for ; Fri, 22 Jun 2001 09:01:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 09:08:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19970 for ; Fri, 22 Jun 2001 09:08:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 09:14:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20234 for ; Fri, 22 Jun 2001 09:14:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 09:20:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20408 for ; Fri, 22 Jun 2001 09:20:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 09:26:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20706 for ; Fri, 22 Jun 2001 09:26:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 09:32:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20882 for ; Fri, 22 Jun 2001 09:32:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 09:38:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21123 for ; Fri, 22 Jun 2001 09:38:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 09:45:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21342 for ; Fri, 22 Jun 2001 09:45:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 09:52:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21609 for ; Fri, 22 Jun 2001 09:52:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 10:52:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23955 for ; Fri, 22 Jun 2001 10:52:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 12:24:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29158 for ; Fri, 22 Jun 2001 12:24:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 14:39:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03987 for ; Fri, 22 Jun 2001 14:39:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DVC9-000HQC-00 for multi6-data@psg.com; Fri, 22 Jun 2001 10:58:13 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15DVC8-000HQ6-00 for multi6@ops.ietf.org; Fri, 22 Jun 2001 10:58:12 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 22 Jun 2001 10:58:11 -0700 Message-ID: <00c201c0fb44$e6ae62b0$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Mohan Parthasarathy" Cc: References: <200106221746.f5MHkxG451082@jurassic.eng.sun.com> Subject: Re: An idea: GxSE Date: Fri, 22 Jun 2001 10:58:11 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 22 Jun 2001 17:58:11.0587 (UTC) FILETIME=[E6DB8D30:01C0FB44] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > There was another suggestion that we can rewrite the destination > address by DSBR, that will also break IPsec because you can't > locate the SA (SAs are looked up using dst_addr, SPI). I agree > that it might be too early to discuss about IPsec issues. > Clearly IPsec would have to change to accomodate this. I assume something like use the ID part of the source address and the whole destination address as part of the encrypted body, and use the SPI and any of the list of addresses to identify the incoming packet. PF From owner-multi6@ops.ietf.org Fri Jun 22 14:39:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03995 for ; Fri, 22 Jun 2001 14:39:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DV1j-000HFy-00 for multi6-data@psg.com; Fri, 22 Jun 2001 10:47:27 -0700 Received: from mercury.sun.com ([192.9.25.1]) by psg.com with esmtp (Exim 3.16 #1) id 15DV1i-000HFq-00 for multi6@ops.ietf.org; Fri, 22 Jun 2001 10:47:26 -0700 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14477; Fri, 22 Jun 2001 10:47:20 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id KAA00058; Fri, 22 Jun 2001 10:48:22 -0700 (PDT) Received: from locked (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5MHkxG451082; Fri, 22 Jun 2001 10:46:59 -0700 (PDT) Message-Id: <200106221746.f5MHkxG451082@jurassic.eng.sun.com> Date: Fri, 22 Jun 2001 10:45:41 -0700 (PDT) From: Mohan Parthasarathy Reply-To: Mohan Parthasarathy Subject: Re: An idea: GxSE To: Erik.Nordmark@eng.sun.com, paul@francis.com Cc: multi6@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: zZ3/eBuc1aCaEXM4h30P8w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-multi6@ops.ietf.org Precedence: bulk > > > > Every host knows at least one (and typically only one) address for > itself, > > > called the self-known address (SK address). The SK address may or may > not > > > be globally routable, but must be globally unique. > > > > I think that today there are distributed (multi-party) applications > > that depend on an application being able to extract a globally routable > > IP address of the box (so that it can be passed to peers etc). > > It would be good to run the idea of apps not knowing their GR addresses > > passed folks with better application knowledge. > > > > It the applications need to know the GR addresses but the host itself > > doesn't know them then it seems like you need a way to map from SK > > to GR addresses. > > I think you are mis-understanding the model a little here (cause I wasn't > clear about this aspect in the original message). Applications should > operate in terms of passing the entire list of addresses around. SK > addresses should not be thought of as some magic token that can be used by > applications to learn GR addresses. Applications should know the GR > addresses from the start. So here is the basic model: > > 1. A DNS lookup on the FQDN will return you the GR addresses (if you are > outside the target's site), suggesting that at least for the initial > contact, the application should be aware of the FQDN not the addresses. > 2. Applications should be aware of the complete list of addresses, not just > the SK address. Obviously this is tricky if a host doesn't know its own > complete list of addresses. But what I have in mind is this: > > The socket API has a set of calls like this: > > getcurrentaddresslist1(sock_id) > or > getcurrentaddresslist2(sk_address) > or > getcurrentaddresslist3(fqdn) > > When host A talks to host B, host B learns the list of addresses by making > one of the above calls. Ideally host A never "identifies" itself to host B > in the application, host B simply does the first call while the socket is > still up, learns the whole list, and uses the whole list whenever it > identifies A, either internally or when talking to a third application at > host C. If for some reason it is necessary for host A to send its identity > to host B in the application layer, host A should preferably use its FQDN, > but could also use its SK address. > As part of IPsec processing, when an inbound packet is decrypted/ authenticated (section 5.2.1 bullet 2 of RFC 2401) there is selector verification i.e it verifies whether the source address of the packet is the same as the one that was used in SA negotiation. Host A would use an SK address while setting up the SA but it is never sent end to end, so there would be a problem. There was another suggestion that we can rewrite the destination address by DSBR, that will also break IPsec because you can't locate the SA (SAs are looked up using dst_addr, SPI). I agree that it might be too early to discuss about IPsec issues. -mohan > The second or thir call could be then used by host B if the socket has > closed. If host B's "network layer" (kernel or whatever) has forgotten the > list, then both the FQDN or the SK address could be used by DNS to obtain > the list, but the third one is more likely to succeed (and requiring that > reverse lookups on SK addresses work even if they are not globally routable > is possible but puts more constraints on SK addresses). > > Ideally the first call would be used wherever possible. > > Anyway, once host B's application gets the whole list, which it can do > without host A knowing what the list is, it can send the whole list to host > C so that subsequently host C can access host A without resorting to DNS. > > > I don't think the above is real pretty---it is the cost one pays for > isolating site addressing from global addressing and getting rid of the > renumbering burden. > > > > > > > The list of addresses (GR and SK) is conveyed to partner hosts by an > IPv6 > > > extension header---the address-list extension. This header is typically > > > added by the site border router as the packet exits the site. (It could > > > > Having intermediate nodes change the length of the packet does cause some > > issues with path MTU discovery. That's why encapsulation is normally used > > (e.g. in mobile IP) to deal with this. > > An alternative approach would be to have the host attach a syntactically > correct address-list extension, but with empty place-holders for the GR > prefix list (instead of the "address-list trigger" extension I suggested > before). There would be a learning mechanism, whereby address-list > extensions would have a field indicating the number of GR prefixes, and this > field would be set on incoming packets. So if the host doesn't know the > number of prefixes, it would use a default, say 4. If it chooses too small > of a number, then it would learn that in a subsequent return packet. Of > course now the partner host would not have the complete list, but this would > not be a disaster. (Alternatively the sending host could always add one > more GR prefix placeholder than it thinks it needs, to catch the case where > a new prefix has recently been added.) > > Of course one could take this one step further, and simply have the > destination host return the source host's list of GR prefixes in the return > packet, so that the source host knows it too (on a connection by connection > basis---this would not be something the source host could generalize about > once the connection was closed). This could be an option selectable by the > application...(ah, the complexity creeps in!!!!) > > > > > > Pseudo-header checksums and IPsec would I suppose be based on the SK > address > > > only (not the GR addresses). > > > > It would be good to look at the effects of bit errors in the source GR > address. > > With no IPv6 header checksum and the GR address not being part of the > > pseudo-header checksum means that it is unprotected. (Perhaps having a > > checksum on the address-list extension can catch this.) > > > > Thinking about it a bit more, pseudo-header checksumming the SK address, > when in fact it isn't even sent end-to-end, sounds kind of stupid...maybe > better to cover just the ID part of the source address (and the full > destination address, which doesn't get translated), and let it go at that. > > PF > > > From owner-multi6@ops.ietf.org Fri Jun 22 14:39:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04007 for ; Fri, 22 Jun 2001 14:39:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DU33-000Gat-00 for multi6-data@psg.com; Fri, 22 Jun 2001 09:44:45 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15DU32-000Gal-00 for multi6@ops.ietf.org; Fri, 22 Jun 2001 09:44:44 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 22 Jun 2001 09:44:43 -0700 Message-ID: <008301c0fb3a$a34580d0$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Erik Nordmark" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Fri, 22 Jun 2001 09:44:43 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 22 Jun 2001 16:44:43.0583 (UTC) FILETIME=[A37B84F0:01C0FB3A] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Every host knows at least one (and typically only one) address for itself, > > called the self-known address (SK address). The SK address may or may not > > be globally routable, but must be globally unique. > > I think that today there are distributed (multi-party) applications > that depend on an application being able to extract a globally routable > IP address of the box (so that it can be passed to peers etc). > It would be good to run the idea of apps not knowing their GR addresses > passed folks with better application knowledge. > > It the applications need to know the GR addresses but the host itself > doesn't know them then it seems like you need a way to map from SK > to GR addresses. I think you are mis-understanding the model a little here (cause I wasn't clear about this aspect in the original message). Applications should operate in terms of passing the entire list of addresses around. SK addresses should not be thought of as some magic token that can be used by applications to learn GR addresses. Applications should know the GR addresses from the start. So here is the basic model: 1. A DNS lookup on the FQDN will return you the GR addresses (if you are outside the target's site), suggesting that at least for the initial contact, the application should be aware of the FQDN not the addresses. 2. Applications should be aware of the complete list of addresses, not just the SK address. Obviously this is tricky if a host doesn't know its own complete list of addresses. But what I have in mind is this: The socket API has a set of calls like this: getcurrentaddresslist1(sock_id) or getcurrentaddresslist2(sk_address) or getcurrentaddresslist3(fqdn) When host A talks to host B, host B learns the list of addresses by making one of the above calls. Ideally host A never "identifies" itself to host B in the application, host B simply does the first call while the socket is still up, learns the whole list, and uses the whole list whenever it identifies A, either internally or when talking to a third application at host C. If for some reason it is necessary for host A to send its identity to host B in the application layer, host A should preferably use its FQDN, but could also use its SK address. The second or thir call could be then used by host B if the socket has closed. If host B's "network layer" (kernel or whatever) has forgotten the list, then both the FQDN or the SK address could be used by DNS to obtain the list, but the third one is more likely to succeed (and requiring that reverse lookups on SK addresses work even if they are not globally routable is possible but puts more constraints on SK addresses). Ideally the first call would be used wherever possible. Anyway, once host B's application gets the whole list, which it can do without host A knowing what the list is, it can send the whole list to host C so that subsequently host C can access host A without resorting to DNS. I don't think the above is real pretty---it is the cost one pays for isolating site addressing from global addressing and getting rid of the renumbering burden. > > > The list of addresses (GR and SK) is conveyed to partner hosts by an IPv6 > > extension header---the address-list extension. This header is typically > > added by the site border router as the packet exits the site. (It could > > Having intermediate nodes change the length of the packet does cause some > issues with path MTU discovery. That's why encapsulation is normally used > (e.g. in mobile IP) to deal with this. An alternative approach would be to have the host attach a syntactically correct address-list extension, but with empty place-holders for the GR prefix list (instead of the "address-list trigger" extension I suggested before). There would be a learning mechanism, whereby address-list extensions would have a field indicating the number of GR prefixes, and this field would be set on incoming packets. So if the host doesn't know the number of prefixes, it would use a default, say 4. If it chooses too small of a number, then it would learn that in a subsequent return packet. Of course now the partner host would not have the complete list, but this would not be a disaster. (Alternatively the sending host could always add one more GR prefix placeholder than it thinks it needs, to catch the case where a new prefix has recently been added.) Of course one could take this one step further, and simply have the destination host return the source host's list of GR prefixes in the return packet, so that the source host knows it too (on a connection by connection basis---this would not be something the source host could generalize about once the connection was closed). This could be an option selectable by the application...(ah, the complexity creeps in!!!!) > > > Pseudo-header checksums and IPsec would I suppose be based on the SK address > > only (not the GR addresses). > > It would be good to look at the effects of bit errors in the source GR address. > With no IPv6 header checksum and the GR address not being part of the > pseudo-header checksum means that it is unprotected. (Perhaps having a > checksum on the address-list extension can catch this.) > Thinking about it a bit more, pseudo-header checksumming the SK address, when in fact it isn't even sent end-to-end, sounds kind of stupid...maybe better to cover just the ID part of the source address (and the full destination address, which doesn't get translated), and let it go at that. PF From owner-multi6@ops.ietf.org Fri Jun 22 14:39:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04018 for ; Fri, 22 Jun 2001 14:39:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 14:45:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04258 for ; Fri, 22 Jun 2001 14:45:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 14:50:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04508 for ; Fri, 22 Jun 2001 14:50:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 14:58:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04811 for ; Fri, 22 Jun 2001 14:58:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 15:14:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05537 for ; Fri, 22 Jun 2001 15:14:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 15:19:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05745 for ; Fri, 22 Jun 2001 15:19:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 15:25:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06036 for ; Fri, 22 Jun 2001 15:25:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 15:31:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06446 for ; Fri, 22 Jun 2001 15:31:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 15:37:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06694 for ; Fri, 22 Jun 2001 15:37:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 15:44:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07022 for ; Fri, 22 Jun 2001 15:44:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 15:50:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07344 for ; Fri, 22 Jun 2001 15:50:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 15:56:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07612 for ; Fri, 22 Jun 2001 15:56:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 16:01:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07884 for ; Fri, 22 Jun 2001 16:01:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 16:10:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08146 for ; Fri, 22 Jun 2001 16:10:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 16:19:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08490 for ; Fri, 22 Jun 2001 16:19:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 16:24:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08730 for ; Fri, 22 Jun 2001 16:24:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 16:29:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08904 for ; Fri, 22 Jun 2001 16:29:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 16:35:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09190 for ; Fri, 22 Jun 2001 16:35:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 16:40:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09394 for ; Fri, 22 Jun 2001 16:40:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 16:46:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09591 for ; Fri, 22 Jun 2001 16:46:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 16:52:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09790 for ; Fri, 22 Jun 2001 16:52:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 17:04:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10169 for ; Fri, 22 Jun 2001 17:04:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 17:12:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10689 for ; Fri, 22 Jun 2001 17:12:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 17:18:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11264 for ; Fri, 22 Jun 2001 17:18:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 18:19:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13450 for ; Fri, 22 Jun 2001 18:19:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 18:44:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13943 for ; Fri, 22 Jun 2001 18:44:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 18:50:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14045 for ; Fri, 22 Jun 2001 18:50:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 18:56:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14268 for ; Fri, 22 Jun 2001 18:56:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 19:02:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14505 for ; Fri, 22 Jun 2001 19:02:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 19:07:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14644 for ; Fri, 22 Jun 2001 19:07:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 19:18:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14763 for ; Fri, 22 Jun 2001 19:18:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 19:23:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14867 for ; Fri, 22 Jun 2001 19:23:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 19:29:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15026 for ; Fri, 22 Jun 2001 19:29:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 19:35:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15214 for ; Fri, 22 Jun 2001 19:35:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 19:40:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15304 for ; Fri, 22 Jun 2001 19:40:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 19:46:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15489 for ; Fri, 22 Jun 2001 19:46:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 19:51:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15584 for ; Fri, 22 Jun 2001 19:51:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 19:59:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16293 for ; Fri, 22 Jun 2001 19:59:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 20:05:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16443 for ; Fri, 22 Jun 2001 20:05:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 20:10:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16512 for ; Fri, 22 Jun 2001 20:10:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 20:16:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16590 for ; Fri, 22 Jun 2001 20:16:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 20:22:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16667 for ; Fri, 22 Jun 2001 20:22:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 20:28:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16737 for ; Fri, 22 Jun 2001 20:28:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 20:33:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16834 for ; Fri, 22 Jun 2001 20:33:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 20:39:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16925 for ; Fri, 22 Jun 2001 20:39:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 21:40:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18751 for ; Fri, 22 Jun 2001 21:40:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Fri Jun 22 23:11:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20717 for ; Fri, 22 Jun 2001 23:11:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 01:27:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24130 for ; Sat, 23 Jun 2001 01:27:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 04:52:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08624 for ; Sat, 23 Jun 2001 04:52:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 09:57:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11290 for ; Sat, 23 Jun 2001 09:57:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 10:03:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11332 for ; Sat, 23 Jun 2001 10:03:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 10:09:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11374 for ; Sat, 23 Jun 2001 10:09:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 10:15:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11480 for ; Sat, 23 Jun 2001 10:15:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 10:22:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11515 for ; Sat, 23 Jun 2001 10:22:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 10:28:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11561 for ; Sat, 23 Jun 2001 10:28:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 10:33:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11646 for ; Sat, 23 Jun 2001 10:33:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 10:39:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11681 for ; Sat, 23 Jun 2001 10:39:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 10:45:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11741 for ; Sat, 23 Jun 2001 10:45:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 10:51:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11774 for ; Sat, 23 Jun 2001 10:51:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 10:57:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11834 for ; Sat, 23 Jun 2001 10:57:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 11:03:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11888 for ; Sat, 23 Jun 2001 11:03:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 11:09:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11965 for ; Sat, 23 Jun 2001 11:09:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 11:15:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12016 for ; Sat, 23 Jun 2001 11:15:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 11:21:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12066 for ; Sat, 23 Jun 2001 11:21:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 11:27:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12132 for ; Sat, 23 Jun 2001 11:27:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 11:33:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12177 for ; Sat, 23 Jun 2001 11:33:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 11:40:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12296 for ; Sat, 23 Jun 2001 11:40:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 11:45:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12437 for ; Sat, 23 Jun 2001 11:45:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 11:51:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12496 for ; Sat, 23 Jun 2001 11:51:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 11:56:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12544 for ; Sat, 23 Jun 2001 11:56:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 12:02:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12620 for ; Sat, 23 Jun 2001 12:02:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 13:03:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13289 for ; Sat, 23 Jun 2001 13:03:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 14:35:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15056 for ; Sat, 23 Jun 2001 14:35:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 16:51:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17254 for ; Sat, 23 Jun 2001 16:51:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 16:57:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17334 for ; Sat, 23 Jun 2001 16:57:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 17:02:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17414 for ; Sat, 23 Jun 2001 17:02:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 17:09:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17478 for ; Sat, 23 Jun 2001 17:09:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 17:15:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17568 for ; Sat, 23 Jun 2001 17:15:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 17:21:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17642 for ; Sat, 23 Jun 2001 17:21:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 17:27:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17702 for ; Sat, 23 Jun 2001 17:27:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 17:34:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17829 for ; Sat, 23 Jun 2001 17:34:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 17:40:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17898 for ; Sat, 23 Jun 2001 17:40:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 17:51:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18014 for ; Sat, 23 Jun 2001 17:51:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 17:56:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18088 for ; Sat, 23 Jun 2001 17:56:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 18:12:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18304 for ; Sat, 23 Jun 2001 18:12:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 18:17:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18352 for ; Sat, 23 Jun 2001 18:17:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 18:23:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18399 for ; Sat, 23 Jun 2001 18:23:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 18:29:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18428 for ; Sat, 23 Jun 2001 18:29:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 18:35:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18490 for ; Sat, 23 Jun 2001 18:35:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 18:40:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18529 for ; Sat, 23 Jun 2001 18:40:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 18:46:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18567 for ; Sat, 23 Jun 2001 18:46:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 18:52:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18716 for ; Sat, 23 Jun 2001 18:52:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 18:58:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18787 for ; Sat, 23 Jun 2001 18:58:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 19:04:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18904 for ; Sat, 23 Jun 2001 19:04:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 19:10:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19008 for ; Sat, 23 Jun 2001 19:10:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 19:16:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19054 for ; Sat, 23 Jun 2001 19:16:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 19:31:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19212 for ; Sat, 23 Jun 2001 19:31:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 19:37:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19274 for ; Sat, 23 Jun 2001 19:37:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 19:42:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19314 for ; Sat, 23 Jun 2001 19:42:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 19:48:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19370 for ; Sat, 23 Jun 2001 19:48:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 19:54:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19427 for ; Sat, 23 Jun 2001 19:54:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 20:00:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19484 for ; Sat, 23 Jun 2001 20:00:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 20:06:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19556 for ; Sat, 23 Jun 2001 20:06:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 20:12:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19654 for ; Sat, 23 Jun 2001 20:12:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 20:18:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19684 for ; Sat, 23 Jun 2001 20:18:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 20:24:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19738 for ; Sat, 23 Jun 2001 20:24:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 20:29:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19783 for ; Sat, 23 Jun 2001 20:29:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 20:34:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19838 for ; Sat, 23 Jun 2001 20:34:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 20:40:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19880 for ; Sat, 23 Jun 2001 20:40:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 20:46:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19918 for ; Sat, 23 Jun 2001 20:46:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 20:51:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19964 for ; Sat, 23 Jun 2001 20:51:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 20:57:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19994 for ; Sat, 23 Jun 2001 20:57:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 21:03:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20043 for ; Sat, 23 Jun 2001 21:03:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 21:08:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20081 for ; Sat, 23 Jun 2001 21:08:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 21:14:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20128 for ; Sat, 23 Jun 2001 21:14:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 21:19:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20166 for ; Sat, 23 Jun 2001 21:19:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 21:24:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20232 for ; Sat, 23 Jun 2001 21:24:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 21:30:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20290 for ; Sat, 23 Jun 2001 21:30:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 21:36:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21264 for ; Sat, 23 Jun 2001 21:36:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sat Jun 23 22:36:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22515 for ; Sat, 23 Jun 2001 22:36:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 00:06:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23537 for ; Sun, 24 Jun 2001 00:06:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DySK-0000Xg-00 for multi6-data@psg.com; Sat, 23 Jun 2001 18:12:52 -0700 Received: from [63.108.254.91] (helo=gnat.inet.org) by psg.com with esmtp (Exim 3.16 #1) id 15DySH-0000WX-00 for multi6@ops.ietf.org; Sat, 23 Jun 2001 18:12:50 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 494F28266E for ; Sat, 23 Jun 2001 21:12:05 -0400 (EDT) Message-Id: <5.1.0.14.2.20010623205501.00acc2a0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 23 Jun 2001 21:08:14 -0400 To: multi6@ops.ietf.org From: RJ Atkinson Subject: Re: GxSE & ESP/AH In-Reply-To: <00c201c0fb44$e6ae62b0$50030a0a@tahoenetworks.com> References: <200106221746.f5MHkxG451082@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk Earlier, Mohan said: >> There was another suggestion that we can rewrite the destination >> address by DSBR, that will also break IPsec because you can't >> locate the SA (SAs are looked up using dst_addr, SPI). I agree >> that it might be too early to discuss about IPsec issues. At 13:58 22/06/01, Paul Francis wrote: >Clearly IPsec would have to change to accomodate this. I assume >something like use the ID part of the source address and the >whole destination address as part of the encrypted body, >and use the SPI and any of the list of addresses to identify >the incoming packet. I'll use precise terms (ESP/AH) rather than imprecise terms (IPsec) in this note. I've never quite puzzled out what "IPsec" precisely means, so try not to use it when precision counts... ESP/AH use the Destination IP Address & SPI for locating the Security Association applicable to an incoming packet. The SPI is not affected by GSE or GxSE, so won't be discussed further. The Destination IP Address was chosen instead of the Source IP Address because of the need to fully support IP multicasting. The use of any *IP address* for this purpose has always been known to be undesirable and a by-product of an insufficiently rich naming architecture for The Internet. The right answer has always been to use a topologically-independent namespace for ESP/AH purposes, but no such namespace exists and is widely deployed today. Note well that DNS does NOT work for this because a FQDN does NOT uniquely name a single TCP/IP stack -- instead an FQDN quite often names a service or content (e.g. www.cnn.com is NOT a system, but rather a cluster of servers with a middle box in front). Now, the original GSE proposal was sunk in its original form as soon as the "Privacy (sic) Address Autoconfiguration Extension" appeared, because the low order bits could no longer (probabilistically) identify a single TCP/IP stack. Some work is going on in the IRTF Namespace Research Group (NSRG) on whether one or more new namespaces would be appropriate to add to the Internet Architecture. IMHO, the NSRG is unlikely to achieve unanimity on this question, though some form of very rough consensus seems possible. HIP is an example of an item that has come out of the NSRG. THere is one more proposal (at least) still cooking in the NSRG. My own view, which dates back at least to the early 90s, is that we need to have a topologically independent namespace for individual systems. If such existed, it would be worthwhile, IMHO, to spin ESP/AH to take advantage of this capability. Bottom line is that ESP/AH is NOT a reason to stop work that is otherwise useful. It is helpful, however, to consider how ESP/AH will need to be tweaked depending on what happens with a given proposal for multihoming. Ran rja@inet.org From owner-multi6@ops.ietf.org Sun Jun 24 00:10:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23544 for ; Sun, 24 Jun 2001 00:06:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 00:12:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23604 for ; Sun, 24 Jun 2001 00:12:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 00:18:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23626 for ; Sun, 24 Jun 2001 00:18:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 00:26:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23684 for ; Sun, 24 Jun 2001 00:26:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 00:31:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23743 for ; Sun, 24 Jun 2001 00:31:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 00:37:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23779 for ; Sun, 24 Jun 2001 00:37:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 00:43:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23815 for ; Sun, 24 Jun 2001 00:43:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 00:48:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23851 for ; Sun, 24 Jun 2001 00:48:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 00:55:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23890 for ; Sun, 24 Jun 2001 00:55:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 01:00:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23964 for ; Sun, 24 Jun 2001 01:00:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 01:07:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24103 for ; Sun, 24 Jun 2001 01:07:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 01:13:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24496 for ; Sun, 24 Jun 2001 01:13:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 01:18:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24877 for ; Sun, 24 Jun 2001 01:18:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 01:23:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25201 for ; Sun, 24 Jun 2001 01:23:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 01:29:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25591 for ; Sun, 24 Jun 2001 01:29:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 01:35:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25872 for ; Sun, 24 Jun 2001 01:34:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 01:41:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26165 for ; Sun, 24 Jun 2001 01:41:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 01:47:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26494 for ; Sun, 24 Jun 2001 01:47:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 01:53:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26937 for ; Sun, 24 Jun 2001 01:53:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 01:59:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27279 for ; Sun, 24 Jun 2001 01:59:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 02:06:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05148 for ; Sun, 24 Jun 2001 02:06:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 02:12:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05611 for ; Sun, 24 Jun 2001 02:12:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 03:13:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01007 for ; Sun, 24 Jun 2001 03:13:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 04:43:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06144 for ; Sun, 24 Jun 2001 04:43:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 07:00:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09483 for ; Sun, 24 Jun 2001 07:00:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 07:01:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09520 for ; Sun, 24 Jun 2001 07:01:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 07:02:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09541 for ; Sun, 24 Jun 2001 07:02:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 07:08:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09631 for ; Sun, 24 Jun 2001 07:08:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 07:14:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09710 for ; Sun, 24 Jun 2001 07:14:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 07:19:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09800 for ; Sun, 24 Jun 2001 07:19:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 07:26:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09896 for ; Sun, 24 Jun 2001 07:26:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 07:33:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09961 for ; Sun, 24 Jun 2001 07:33:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 07:39:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10078 for ; Sun, 24 Jun 2001 07:39:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 07:45:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10185 for ; Sun, 24 Jun 2001 07:45:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 07:51:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10247 for ; Sun, 24 Jun 2001 07:51:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 07:57:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10315 for ; Sun, 24 Jun 2001 07:57:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 08:03:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10412 for ; Sun, 24 Jun 2001 08:03:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 08:08:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10462 for ; Sun, 24 Jun 2001 08:08:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 08:14:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10648 for ; Sun, 24 Jun 2001 08:14:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 08:19:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10748 for ; Sun, 24 Jun 2001 08:19:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 08:25:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10782 for ; Sun, 24 Jun 2001 08:25:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 08:31:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10879 for ; Sun, 24 Jun 2001 08:31:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 08:36:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10956 for ; Sun, 24 Jun 2001 08:36:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 08:43:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11058 for ; Sun, 24 Jun 2001 08:43:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 08:49:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11124 for ; Sun, 24 Jun 2001 08:49:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 08:55:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11226 for ; Sun, 24 Jun 2001 08:55:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 09:00:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11279 for ; Sun, 24 Jun 2001 09:00:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 09:06:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11390 for ; Sun, 24 Jun 2001 09:06:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 10:09:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11853 for ; Sun, 24 Jun 2001 10:09:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 11:39:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12544 for ; Sun, 24 Jun 2001 11:39:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 13:55:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13777 for ; Sun, 24 Jun 2001 13:55:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 14:01:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13829 for ; Sun, 24 Jun 2001 14:01:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 14:07:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13871 for ; Sun, 24 Jun 2001 14:07:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 14:13:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13924 for ; Sun, 24 Jun 2001 14:13:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 14:19:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13986 for ; Sun, 24 Jun 2001 14:19:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 14:25:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14060 for ; Sun, 24 Jun 2001 14:25:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 14:31:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14139 for ; Sun, 24 Jun 2001 14:31:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 14:37:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14171 for ; Sun, 24 Jun 2001 14:37:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 14:42:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14214 for ; Sun, 24 Jun 2001 14:42:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 14:49:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14248 for ; Sun, 24 Jun 2001 14:49:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 14:54:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14285 for ; Sun, 24 Jun 2001 14:54:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 15:00:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14344 for ; Sun, 24 Jun 2001 14:59:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 15:05:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14493 for ; Sun, 24 Jun 2001 15:05:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 15:12:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14567 for ; Sun, 24 Jun 2001 15:12:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 15:18:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14626 for ; Sun, 24 Jun 2001 15:18:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 15:25:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14733 for ; Sun, 24 Jun 2001 15:25:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 15:31:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14825 for ; Sun, 24 Jun 2001 15:31:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 15:38:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14884 for ; Sun, 24 Jun 2001 15:38:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 15:46:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14985 for ; Sun, 24 Jun 2001 15:46:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 15:53:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15082 for ; Sun, 24 Jun 2001 15:53:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 16:01:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15184 for ; Sun, 24 Jun 2001 16:00:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 17:06:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16039 for ; Sun, 24 Jun 2001 17:06:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 18:37:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16525 for ; Sun, 24 Jun 2001 18:37:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Sun Jun 24 20:53:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17533 for ; Sun, 24 Jun 2001 20:53:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 00:16:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21272 for ; Mon, 25 Jun 2001 00:16:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 00:22:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21299 for ; Mon, 25 Jun 2001 00:22:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 00:27:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21335 for ; Mon, 25 Jun 2001 00:27:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 00:33:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21410 for ; Mon, 25 Jun 2001 00:33:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 00:38:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21465 for ; Mon, 25 Jun 2001 00:38:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 00:45:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21500 for ; Mon, 25 Jun 2001 00:45:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 00:52:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21666 for ; Mon, 25 Jun 2001 00:52:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 00:59:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21716 for ; Mon, 25 Jun 2001 00:59:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 01:06:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21831 for ; Mon, 25 Jun 2001 01:06:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 01:14:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22331 for ; Mon, 25 Jun 2001 01:14:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 01:20:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22731 for ; Mon, 25 Jun 2001 01:20:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 01:26:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23094 for ; Mon, 25 Jun 2001 01:26:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 01:32:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23510 for ; Mon, 25 Jun 2001 01:32:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 01:38:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23801 for ; Mon, 25 Jun 2001 01:38:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 01:44:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24030 for ; Mon, 25 Jun 2001 01:44:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 01:51:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24443 for ; Mon, 25 Jun 2001 01:51:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 01:58:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24941 for ; Mon, 25 Jun 2001 01:58:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 02:05:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02136 for ; Mon, 25 Jun 2001 02:05:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 02:12:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03299 for ; Mon, 25 Jun 2001 02:12:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 02:19:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03700 for ; Mon, 25 Jun 2001 02:19:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 03:21:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07963 for ; Mon, 25 Jun 2001 03:21:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 04:53:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09051 for ; Mon, 25 Jun 2001 04:53:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 07:10:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10294 for ; Mon, 25 Jun 2001 07:10:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 10:33:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16549 for ; Mon, 25 Jun 2001 10:33:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15ERoD-000F58-00 for multi6-data@psg.com; Mon, 25 Jun 2001 01:33:25 -0700 Received: from mercury.sun.com ([192.9.25.1]) by psg.com with esmtp (Exim 3.16 #1) id 15ERoC-000F52-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 01:33:24 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA29414; Mon, 25 Jun 2001 01:33:21 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f5P8XE711156; Mon, 25 Jun 2001 10:33:14 +0200 (MET DST) Date: Mon, 25 Jun 2001 10:32:45 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: An idea: GxSE To: Paul Francis Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <008301c0fb3a$a34580d0$50030a0a@tahoenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id KAA16549 > I think you are mis-understanding the model a little here (cause I wasn't > clear about this aspect in the original message). Applications should > operate in terms of passing the entire list of addresses around. SK > addresses should not be thought of as some magic token that can be used by > applications to learn GR addresses. Applications should know the GR > addresses from the start. How does an application learn its own GR addresses? > 1. A DNS lookup on the FQDN will return you the GR addresses (if you are > outside the target's site), suggesting that at least for the initial > contact, the application should be aware of the FQDN not the addresses. For the peer this is fine. But what about itself? > When host A talks to host B, host B learns the list of addresses by making > one of the above calls. Ideally host A never "identifies" itself to host B > in the application, host B simply does the first call while the socket is > still up, learns the whole list, and uses the whole list whenever it > identifies A, either internally or when talking to a third application at > host C. If for some reason it is necessary for host A to send its identity > to host B in the application layer, host A should preferably use its FQDN, > but could also use its SK address. I see how that can be made to work. The point is that I think this is a significant change in the way applications deal with their own addresses. Today they can just use getsockname(int sock,...) and pass this to peers. Thus whatever the new architecture needs to be for applications (handling addresses) the ramifications of this is best understood by folks with apps clue. I don't know how many of those we have on this list. BTW: Working out how IKE would work in the GxSE architecture would be a good test. (Even though IKE isn't a multi-party application it passes IP addresses around.) > An alternative approach would be to have the host attach a syntactically > correct address-list extension, but with empty place-holders for the GR > prefix list (instead of the "address-list trigger" extension I suggested > before). There would be a learning mechanism, whereby address-list > extensions would have a field indicating the number of GR prefixes, and this > field would be set on incoming packets. So if the host doesn't know the > number of prefixes, it would use a default, say 4. If it chooses too small > of a number, then it would learn that in a subsequent return packet. Of > course now the partner host would not have the complete list, but this would > not be a disaster. (Alternatively the sending host could always add one > more GR prefix placeholder than it thinks it needs, to catch the case where > a new prefix has recently been added.) I had the same idea. At least it works better than changing the length of the packets in the border routers. > Of course one could take this one step further, and simply have the > destination host return the source host's list of GR prefixes in the return > packet, so that the source host knows it too (on a connection by connection > basis---this would not be something the source host could generalize about > once the connection was closed). This could be an option selectable by the > application...(ah, the complexity creeps in!!!!) In a sense your moving the complexity of the routing system to handle scalable multihoming to the transport and applications layers. Erik From owner-multi6@ops.ietf.org Mon Jun 25 10:34:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16606 for ; Mon, 25 Jun 2001 10:34:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 10:35:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16660 for ; Mon, 25 Jun 2001 10:35:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 10:41:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16799 for ; Mon, 25 Jun 2001 10:41:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 10:47:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16916 for ; Mon, 25 Jun 2001 10:47:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 10:53:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17059 for ; Mon, 25 Jun 2001 10:53:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 10:59:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17192 for ; Mon, 25 Jun 2001 10:59:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 11:05:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17440 for ; Mon, 25 Jun 2001 11:05:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 11:10:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17582 for ; Mon, 25 Jun 2001 11:10:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EXYZ-000NFQ-00 for multi6-data@psg.com; Mon, 25 Jun 2001 07:41:39 -0700 Received: from [63.108.254.91] (helo=gnat.inet.org) by psg.com with esmtp (Exim 3.16 #1) id 15EXYZ-000NEv-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 07:41:39 -0700 Received: from mosquito.inet.org (rja-laptop [10.30.34.139]) by gnat.inet.org (Postfix) with ESMTP id 3809C8266E; Mon, 25 Jun 2001 10:40:56 -0400 (EDT) Message-Id: <5.1.0.14.2.20010625103502.009f9c60@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Jun 2001 10:37:01 -0400 To: Erik Nordmark From: RJ Atkinson Subject: Re: An idea: GxSE Cc: multi6@ops.ietf.org In-Reply-To: References: <"Your message with ID" <008301c0fb3a$a34580d0$50030a0a@tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 04:32 25/06/01, Erik Nordmark wrote: >In a sense your moving the complexity of the routing system to handle >scalable multihoming to the transport and applications layers. It would be sensible to move the complexity of multihoming into the set of systems that actually are using multihoming. Right now sites that aren't multihomed have to pay the operational costs caused by multihomed sites. If this meant moving some multihoming complexity into the transport layer (compare with SCTP), that would seem entirely reasonable, to me at least. Ran From owner-multi6@ops.ietf.org Mon Jun 25 11:10:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17605 for ; Mon, 25 Jun 2001 11:10:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EXjg-000NYh-00 for multi6-data@psg.com; Mon, 25 Jun 2001 07:53:08 -0700 Received: from openbsd-0.lcs.mit.edu ([18.26.4.157] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.16 #1) id 15EXjf-000NYb-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 07:53:07 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 67B017BB; Mon, 25 Jun 2001 23:52:32 +0900 (JST) To: multi6@ops.ietf.org In-reply-to: rja's message of Mon, 25 Jun 2001 10:37:01 -0400. <5.1.0.14.2.20010625103502.009f9c60@10.30.15.2> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: An idea: GxSE From: Jun-ichiro itojun Hagino Date: Mon, 25 Jun 2001 23:52:32 +0900 Message-Id: <20010625145232.67B017BB@starfruit.itojun.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk sorry if i missed something, but why are we designing a new protocol in this working group? it was chartered that it won't. itojun From owner-multi6@ops.ietf.org Mon Jun 25 11:11:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17664 for ; Mon, 25 Jun 2001 11:11:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 11:13:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17737 for ; Mon, 25 Jun 2001 11:13:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EXsF-000Nnf-00 for multi6-data@psg.com; Mon, 25 Jun 2001 08:01:59 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 15EXsE-000NnW-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 08:01:58 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f5PF2VH01114; Mon, 25 Jun 2001 17:02:32 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 25 Jun 2001 17:01:55 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Paul Francis cc: multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <007001c0f9c5$e26e3200$50030a0a@tahoenetworks.com> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Going back a bit... On Wed, 20 Jun 2001, Paul Francis wrote: > But yes, the requirement here is that the renumbering event be transparent > to end hosts (and also to internal routers). I think this is important for > the same reasons that O'Dell expresses in GSE. I think that sites will not > want to renumber, and will look for cheaper alternatives, of which there are > two: > 1. Convince the ISPs to advertise its prefix across the default-free > routing zone (i.e., what we do today with IPv4) > 2. Use NAT (also what we do with IPv4 today). Renumbering is a pain, but running BGP or NAT is too. I'm not convinced people are as desperate to avoid renumbering as you say. And this is in IPv4. In IPv6 it somewhat unlikely that workstations that do not run any services will be configured manually, and both prefix advertising and DHCP can handle renumbering without too much of a hassle. The only systems that are hard to renumber are those that others frequently connect to. Since you wouldn't want your web server to magically get a new IP address and become unreachable when it gets a new MAC address or someone else uses the same MAC address these are configured manually. But how many web servers do most organizations run? > The goal of GxSE is to provide a solution that is about as easy as NAT, but > provides better functionality (mainly, connections survive in the face of > the site border routing crashing). Ok, but why try to do both at the same time? There are quite a few things we can do to improve NAT: - make it stateless so there is no longer a single point of failure and scalability is improved - add a "NAT control protocol" so applications can instruct the NAT box to enable/disable certain features and find out what their "real" address is There is one thing that NAT has going for it that will kind of break in GxSE: the hosts don't need to do or know anything special. But both the host and the router have to support GxSE. Obviously, when every host runs GxSE this is no longer a problem, but this is not something that is going to happen any time soon. And the same thing goes for using multiple addresses concurrently: if we can implement this without requiring cooperation from the router, it becomes much more usable. Many organizations have their routers supplied by a service provider and are not in the position to update the software or even change the configuration. If they can get a second router from a second ISP and the hosts can use both connections at the same time and use each as a fallback for the other, this would be a very good thing. I've looked at the SCTP RFC some people mentioned, but this is a completely new transport protocol. I don't think this is the way to go: this functionality should be added to TCP or to IP. A good all-purpose solution would be to implement a protocol in IP that monitors connections (yes, even UDP "connections") and negotiates fallback IP addresses with the other host when it detects that the connections stay up for more than a certain time. (It makes no sense to do this for short DNS or HTTP transactions: these benefit more from trying the different addresses for a hostname and caching the unreachability information.) Then if an ICMP unreachable message comes in the destination address for every connection is changed to one of the fallback addresses. The protocol for negotiating more addresses could be fairly simple: the receiving system sends a challenge with a simple one time identifier and the sending system responds to the challenge by returning the identifier and the addresses to be used along with an indication of which is preferred. More complex authentication schemes can be implemented as options. Of course there should be an API so applications can see and control which addresses are used. The next stage would be to adapt TCP to use multiple addresses at the same time. This way it is possible to optimize for delay, packet loss or bandwidth or to use the full bandwidth of the combined connections. A "source addresses a:b:c::/d are now unreachable" broadcast from the routers might also help but is not really necessary. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Jun 25 11:13:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17746 for ; Mon, 25 Jun 2001 11:13:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 11:20:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18002 for ; Mon, 25 Jun 2001 11:20:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 11:25:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18156 for ; Mon, 25 Jun 2001 11:25:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 11:31:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18322 for ; Mon, 25 Jun 2001 11:31:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EY5T-000O8P-00 for multi6-data@psg.com; Mon, 25 Jun 2001 08:15:39 -0700 Received: from [63.108.254.91] (helo=gnat.inet.org) by psg.com with esmtp (Exim 3.16 #1) id 15EY5S-000O8B-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 08:15:39 -0700 Received: from mosquito.inet.org (rja-laptop [10.30.34.139]) by gnat.inet.org (Postfix) with ESMTP id 6A4768266E; Mon, 25 Jun 2001 11:15:07 -0400 (EDT) Message-Id: <5.1.0.14.2.20010625111029.00a1dc60@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Jun 2001 11:11:12 -0400 To: Jun-ichiro itojun Hagino From: RJ Atkinson Subject: Re: An idea: GxSE Cc: multi6@ops.ietf.org In-Reply-To: <20010625145232.67B017BB@starfruit.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 10:52 25/06/01, Jun-ichiro itojun Hagino wrote: > sorry if i missed something, but why are we designing a new protocol > in this working group? it was chartered that it won't. I don't see a new protocol being designed yet. I do see that various approaches to handling IPv6 multihoming are being discussed. Discussion is a fine thing. Ran From owner-multi6@ops.ietf.org Mon Jun 25 11:31:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18336 for ; Mon, 25 Jun 2001 11:31:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 11:38:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18521 for ; Mon, 25 Jun 2001 11:38:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 11:44:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18770 for ; Mon, 25 Jun 2001 11:44:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EYYB-000Opl-00 for multi6-data@psg.com; Mon, 25 Jun 2001 08:45:19 -0700 Received: from sommerfeld.ne.mediaone.net ([24.218.160.210] helo=stack.hamachi.org) by psg.com with esmtp (Exim 3.16 #1) id 15EYYA-000Opf-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 08:45:18 -0700 Received: from orchard.arlington.ma.us (orchard.hamachi.org [4.255.0.98]) by stack.hamachi.org (Postfix) with ESMTP id 128D7270A; Mon, 25 Jun 2001 11:45:13 -0400 (EDT) Received: by orchard.arlington.ma.us (Postfix, from userid 587) id 773772A4B; Mon, 25 Jun 2001 11:45:12 -0400 (EDT) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id 674091FDB; Mon, 25 Jun 2001 11:45:12 -0400 (EDT) From: Bill Sommerfeld To: Jun-ichiro itojun Hagino Cc: RJ Atkinson , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: Message from Jun-ichiro itojun Hagino of "Tue, 26 Jun 2001 00:30:59 +0900." <20010625153059.24F2A7BB@starfruit.itojun.org> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Mon, 25 Jun 2001 11:45:07 -0400 Message-Id: <20010625154512.773772A4B@orchard.arlington.ma.us> Sender: owner-multi6@ops.ietf.org Precedence: bulk > there are a lot of IPv6 implementation already out of the door. > we need to concentrate ourselves to *operational* solution that are > deployable on implementation that are available today (= NO NEW CODE). i do not believe that we will be able to produce a satisfactory multhoming solution without new code. - Bill From owner-multi6@ops.ietf.org Mon Jun 25 11:45:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18798 for ; Mon, 25 Jun 2001 11:45:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 11:53:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19180 for ; Mon, 25 Jun 2001 11:53:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 11:59:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19380 for ; Mon, 25 Jun 2001 11:59:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 12:05:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19495 for ; Mon, 25 Jun 2001 12:05:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EYLA-000OWZ-00 for multi6-data@psg.com; Mon, 25 Jun 2001 08:31:52 -0700 Received: from openbsd-0.lcs.mit.edu ([18.26.4.157] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.16 #1) id 15EYL9-000OW8-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 08:31:51 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 24F2A7BB; Tue, 26 Jun 2001 00:30:59 +0900 (JST) To: RJ Atkinson Cc: multi6@ops.ietf.org In-reply-to: rja's message of Mon, 25 Jun 2001 11:11:12 -0400. <5.1.0.14.2.20010625111029.00a1dc60@10.30.15.2> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: An idea: GxSE From: Jun-ichiro itojun Hagino Date: Tue, 26 Jun 2001 00:30:59 +0900 Message-Id: <20010625153059.24F2A7BB@starfruit.itojun.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk >> sorry if i missed something, but why are we designing a new protocol >> in this working group? it was chartered that it won't. > I don't see a new protocol being designed yet. I >do see that various approaches to handling IPv6 multihoming >are being discussed. Discussion is a fine thing. i agree discussion is a fine thing, but when we have a goal to settle, sometimes we need to limit ourselves to achieve that goal. multi6 charter clearly says that, i believe... you guys are now talking about, under "GxSE" discussion: - new site board router implementation that would rewrite topmost bits in the packet - new host implementation that would recognize peer as a set of addresses why are they not "new protocol design"? if they are not the new protocol design, there's no such thing as "protocol design". there are a lot of IPv6 implementation already out of the door. we need to concentrate ourselves to *operational* solution that are deployable on implementation that are available today (= NO NEW CODE). of course, it is just my opinion. thanks. itojun PS: i have not been too vocal (sorry about that), but i have submitted few drafts, running experiment with others, and such. i would like to report again about RFC2260-ish multihoming with operational results. From owner-multi6@ops.ietf.org Mon Jun 25 12:05:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19505 for ; Mon, 25 Jun 2001 12:05:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 12:13:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19697 for ; Mon, 25 Jun 2001 12:13:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 12:19:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19934 for ; Mon, 25 Jun 2001 12:19:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 12:26:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20080 for ; Mon, 25 Jun 2001 12:26:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 12:32:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20377 for ; Mon, 25 Jun 2001 12:32:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 12:37:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20587 for ; Mon, 25 Jun 2001 12:37:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 12:44:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20803 for ; Mon, 25 Jun 2001 12:44:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 12:51:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21025 for ; Mon, 25 Jun 2001 12:51:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 12:51:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21036 for ; Mon, 25 Jun 2001 12:51:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EZLr-000Ppm-00 for multi6-data@psg.com; Mon, 25 Jun 2001 09:36:39 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 15EZLq-000Ppg-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 09:36:38 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f5PGbAH01235; Mon, 25 Jun 2001 18:37:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 25 Jun 2001 18:36:33 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Bill Sommerfeld cc: multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <20010625154512.773772A4B@orchard.arlington.ma.us> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 25 Jun 2001, Bill Sommerfeld wrote: > > there are a lot of IPv6 implementation already out of the door. > > we need to concentrate ourselves to *operational* solution that are > > deployable on implementation that are available today (= NO NEW CODE). > i do not believe that we will be able to produce a satisfactory > multhoming solution without new code. I don't think the geo solutions need new code. (At least mine doesn't.) Obviously, if new code is not an option, the solution is very likely to be less effective. Also, new code is not really a problem, as long as each site can implement it at their own pace. Unless I overlook something there are basically four ideas to keep the growth of the routing table as a result from multihoming to a minimum: 1. NAT and other address rewriting ideas. Pro: works today. Con: NAT box is a single point of failure, sessions don't survive address change. 2. Layer 4 mobility. Pro: implemented in the hosts, support for multihoming at the NIC level. Con: a lot of new software. 3. Geo addressing. Pro: no (new) software necessary, works in IPv4. Con: routing table effect may be as little as one order of magnitude. 4. More efficient routing information encoding (such as bitmaps). Pro: same hardware can accomodate several orders of magnitude larger routing table. Con: many things: new protocol versions, new software, etc. Obviously, a single solution can implement more than one idea, such as 1 and 2 for GxSE. I think all of these ideas have enough potential to warrant further investigation, even if the time scales for implementation are very different. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Jun 25 12:52:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21052 for ; Mon, 25 Jun 2001 12:52:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 12:57:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21208 for ; Mon, 25 Jun 2001 12:57:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EZUg-00007x-00 for multi6-data@psg.com; Mon, 25 Jun 2001 09:45:46 -0700 Received: from garlic.amaranth.net ([216.235.243.195]) by psg.com with esmtp (Exim 3.16 #1) id 15EZUf-00007r-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 09:45:46 -0700 Received: from yarrow.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f5PGjXl20309 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Mon, 25 Jun 2001 12:45:34 -0400 Message-Id: <5.1.0.14.2.20010625124009.03d48130@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Jun 2001 12:45:33 -0400 To: Iljitsch van Beijnum From: Daniel Senie Subject: Re: An idea: GxSE Cc: multi6@ops.ietf.org In-Reply-To: References: <007001c0f9c5$e26e3200$50030a0a@tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 11:01 AM 6/25/01, Iljitsch van Beijnum wrote: >There are quite a few things we can do to improve NAT: > >- make it stateless so there is no longer a single point of failure and > scalability is improved This is not necessarily a stumbling block for NAT. There are many NAT implementations out there which handle redundancy through the use of duplicate, cooperative hardware, just as well as the web load balancers which can't be a single point of failure. There are also some which handle multi-homing without the use of BGP by using address blocks from separate links and managing load and failover. >- add a "NAT control protocol" so applications can instruct the NAT box to > enable/disable certain features and find out what their "real" address is Please go read the RSIP documents. There are a LOT of problems with this, not the least of which is there may be multiple layers of NAT between a workstation and the global address space. It is quite problematic to deal with these cases, and they ARE common. >There is one thing that NAT has going for it that will kind of break in GxSE: >the hosts don't need to do or know anything special. But both the host and >the router have to support GxSE. Obviously, when every host runs GxSE this is >no longer a problem, but this is not something that is going to happen any >time soon. And since NAT doesn't provide a reliable end-point address in some cases, there's no way to put servers behind it. Or peer-to-peer neworking applications. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-multi6@ops.ietf.org Mon Jun 25 12:58:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21232 for ; Mon, 25 Jun 2001 12:58:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 13:05:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21385 for ; Mon, 25 Jun 2001 13:05:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 13:11:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21482 for ; Mon, 25 Jun 2001 13:11:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EZSi-00004f-00 for multi6-data@psg.com; Mon, 25 Jun 2001 09:43:44 -0700 Received: from [63.108.254.91] (helo=gnat.inet.org) by psg.com with esmtp (Exim 3.16 #1) id 15EZSh-00004B-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 09:43:43 -0700 Received: from mosquito.inet.org (rja-laptop [10.30.34.139]) by gnat.inet.org (Postfix) with ESMTP id 5D1C38266E; Mon, 25 Jun 2001 12:43:07 -0400 (EDT) Message-Id: <5.1.0.14.2.20010625123504.00a656d0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Jun 2001 12:39:10 -0400 To: Jun-ichiro itojun Hagino From: RJ Atkinson Subject: Re: An idea: GxSE Cc: multi6@ops.ietf.org In-Reply-To: <20010625153059.24F2A7BB@starfruit.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 11:30 25/06/01, Jun-ichiro itojun Hagino wrote: > i agree discussion is a fine thing, but when we have a goal to settle, > sometimes we need to limit ourselves to achieve that goal. multi6 > charter clearly says that, i believe... Limiting ourselves so that we rule out possible solutions pre-maturely is not helpful to actually achieving the goal. > there are a lot of IPv6 implementation already out of the door. > we need to concentrate ourselves to *operational* solution that are > deployable on implementation that are available today (= NO NEW CODE). > of course, it is just my opinion. thanks. It is also not required by the charter that only "no new code" approaches be discussed here. It is also the case that, compared with IPv4 deployment, IPv6 deployment is quite small. As a vendor, I can't find *any* potential IPv6 customers that aren't members of the set {Japan, GSM/WCDMA operators, GSM/WCDMA systems integrators}. I hope this will change, but that seems to be today's reality for paying customers. Myself, I doubt that any approach that is operationally practical and resolves the IDR routing table issues caused by multi-homing can be found that requires "no new code". I'd be tickled pink if someone demonstrated such an approach, but haven't heard about one here so far... Yours, Ran rja@inet.org From owner-multi6@ops.ietf.org Mon Jun 25 13:11:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21493 for ; Mon, 25 Jun 2001 13:11:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 13:12:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21529 for ; Mon, 25 Jun 2001 13:12:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 13:18:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21633 for ; Mon, 25 Jun 2001 13:18:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 13:24:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21762 for ; Mon, 25 Jun 2001 13:24:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 13:30:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21891 for ; Mon, 25 Jun 2001 13:30:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EZXt-0000Dn-00 for multi6-data@psg.com; Mon, 25 Jun 2001 09:49:05 -0700 Received: from openbsd-0.lcs.mit.edu ([18.26.4.157] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.16 #1) id 15EZXs-0000Dh-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 09:49:04 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id AB8FB7BB; Tue, 26 Jun 2001 01:47:40 +0900 (JST) To: RJ Atkinson Cc: multi6@ops.ietf.org In-reply-to: rja's message of Mon, 25 Jun 2001 12:39:10 -0400. <5.1.0.14.2.20010625123504.00a656d0@10.30.15.2> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: An idea: GxSE From: Jun-ichiro itojun Hagino Date: Tue, 26 Jun 2001 01:47:40 +0900 Message-Id: <20010625164740.AB8FB7BB@starfruit.itojun.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk > Myself, I doubt that any approach that is operationally >practical and resolves the IDR routing table issues caused by >multi-homing can be found that requires "no new code". I'd be >tickled pink if someone demonstrated such an approach, but haven't >heard about one here so far... well, there are at least two. draft-yu-simple-ipv6multihoming-01.txt draft-ietf-ipngwg-ipv6-2260-01.txt itojun From owner-multi6@ops.ietf.org Mon Jun 25 13:30:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21904 for ; Mon, 25 Jun 2001 13:30:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 13:32:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21987 for ; Mon, 25 Jun 2001 13:32:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EZrl-0000mj-00 for multi6-data@psg.com; Mon, 25 Jun 2001 10:09:37 -0700 Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by psg.com with esmtp (Exim 3.16 #1) id 15EZrk-0000mO-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 10:09:36 -0700 Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id KAA18290; Mon, 25 Jun 2001 10:08:57 -0700 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id KAA19352; Mon, 25 Jun 2001 10:09:02 -0700 Message-ID: <3B376EBE.8ED2A12D@hursley.ibm.com> Date: Mon, 25 Jun 2001 12:02:54 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: sommerfeld@orchard.arlington.ma.us CC: Jun-ichiro itojun Hagino , RJ Atkinson , multi6@ops.ietf.org Subject: Re: An idea: GxSE References: <20010625154512.773772A4B@orchard.arlington.ma.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > > > there are a lot of IPv6 implementation already out of the door. > > we need to concentrate ourselves to *operational* solution that are > > deployable on implementation that are available today (= NO NEW CODE). > > i do not believe that we will be able to produce a satisfactory > multhoming solution without new code. The text I suggested weeks ago for the requirements draft was intended to specify very precisely what is and is not acceptable in the way of new host code. When we get the requirements agreed, we can decide which solutions are worth exploring. Brian From owner-multi6@ops.ietf.org Mon Jun 25 13:34:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22038 for ; Mon, 25 Jun 2001 13:34:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 13:40:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22198 for ; Mon, 25 Jun 2001 13:40:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 13:46:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22340 for ; Mon, 25 Jun 2001 13:46:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 13:52:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22513 for ; Mon, 25 Jun 2001 13:52:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 13:57:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22643 for ; Mon, 25 Jun 2001 13:57:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EaTR-0001mK-00 for multi6-data@psg.com; Mon, 25 Jun 2001 10:48:33 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15EaTQ-0001mE-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 10:48:32 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id MAA16871; Mon, 25 Jun 2001 12:48:41 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Mon, 25 Jun 2001 12:48:41 -0500 (CDT) From: "Jon (Taz) Mischo" To: Jun-ichiro itojun Hagino cc: RJ Atkinson , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <20010625153059.24F2A7BB@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Itojun- I understand how you feel, however, I feel rather strongly that we should do this the right way from the start. One of the biggest problems with NAT is that it was an afterthought, thus broke many things. We're not designing a protocol here, just ways to handle certain situations. Furthermore, we're discussing technology in its infancy. There is no reason not to explore the possibilities. Remember, WE make the rules, so we might as well look at all the options to the good ones. These decisions will be with us for at LEAST a decade, let's make decisions we can deal with. -Taz On Tue, 26 Jun 2001, Jun-ichiro itojun Hagino wrote: > >> sorry if i missed something, but why are we designing a new protocol > >> in this working group? it was chartered that it won't. > > I don't see a new protocol being designed yet. I > >do see that various approaches to handling IPv6 multihoming > >are being discussed. Discussion is a fine thing. > > i agree discussion is a fine thing, but when we have a goal to settle, > sometimes we need to limit ourselves to achieve that goal. multi6 > charter clearly says that, i believe... > > you guys are now talking about, under "GxSE" discussion: > - new site board router implementation that would rewrite topmost > bits in the packet > - new host implementation that would recognize peer as a set of > addresses > why are they not "new protocol design"? if they are not the new > protocol design, there's no such thing as "protocol design". > > there are a lot of IPv6 implementation already out of the door. > we need to concentrate ourselves to *operational* solution that are > deployable on implementation that are available today (= NO NEW CODE). > of course, it is just my opinion. thanks. > > itojun > PS: i have not been too vocal (sorry about that), but i have submitted few > drafts, running experiment with others, and such. i would like to > report again about RFC2260-ish multihoming with operational results. > -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Mon Jun 25 13:57:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22644 for ; Mon, 25 Jun 2001 13:57:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 14:03:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22801 for ; Mon, 25 Jun 2001 14:03:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EaEF-0001Ne-00 for multi6-data@psg.com; Mon, 25 Jun 2001 10:32:51 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 15EaEE-0001Mt-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 10:32:50 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 15EaD7-0000hc-00; Mon, 25 Jun 2001 10:31:41 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brian E Carpenter Cc: multi6@ops.ietf.org Subject: Re: An idea: GxSE References: <20010625154512.773772A4B@orchard.arlington.ma.us> <3B376EBE.8ED2A12D@hursley.ibm.com> Message-Id: Date: Mon, 25 Jun 2001 10:31:41 -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit as we have no running code, i suggest we try to understand the needs, then how they might be achieved, and then, and only then, can we say whether code will need to change or not. considering the vast and pervasive v6 deployment to date as compared to its expected lifetime, i suspect we can afford to get it right. randy From owner-multi6@ops.ietf.org Mon Jun 25 14:03:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22812 for ; Mon, 25 Jun 2001 14:03:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EaPV-0001dG-00 for multi6-data@psg.com; Mon, 25 Jun 2001 10:44:29 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15EaPU-0001dA-00; Mon, 25 Jun 2001 10:44:28 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id MAA16862; Mon, 25 Jun 2001 12:44:40 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Mon, 25 Jun 2001 12:44:40 -0500 (CDT) From: "Jon (Taz) Mischo" To: Randy Bush cc: Brian E Carpenter , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Well said, Randy. On Mon, 25 Jun 2001, Randy Bush wrote: > as we have no running code, i suggest we try to understand the needs, then > how they might be achieved, and then, and only then, can we say whether code > will need to change or not. > > considering the vast and pervasive v6 deployment to date as compared to its > expected lifetime, i suspect we can afford to get it right. > > randy > -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Mon Jun 25 14:04:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22846 for ; Mon, 25 Jun 2001 14:04:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 14:10:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23002 for ; Mon, 25 Jun 2001 14:10:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Ead9-00023L-00 for multi6-data@psg.com; Mon, 25 Jun 2001 10:58:35 -0700 Received: from openbsd-0.lcs.mit.edu ([18.26.4.157] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.16 #1) id 15Ead8-00023B-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 10:58:34 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 68ECC7BB; Tue, 26 Jun 2001 02:56:42 +0900 (JST) To: "Jon (Taz) Mischo" Cc: RJ Atkinson , multi6@ops.ietf.org In-reply-to: taz's message of Mon, 25 Jun 2001 12:48:41 EST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: An idea: GxSE From: Jun-ichiro itojun Hagino Date: Tue, 26 Jun 2001 02:56:42 +0900 Message-Id: <20010625175642.68ECC7BB@starfruit.itojun.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk >I understand how you feel, however, I feel rather strongly that we should >do this the right way from the start. One of the biggest problems with >NAT is that it was an afterthought, thus broke many things. We're not >designing a protocol here, just ways to handle certain situations. i disagree about the "from the start" part. the deployment is already started here and there. maybe this is because i'm in Japan, but i feel it way too late to make any changes to the way routers/hosts work. also, remember why GSE proposal was not integrated into IPv6 - IPv6 is designed based on IPv4 experiences, and tries to benefit from the success of IPv4. if we add too many fundamental design changes into IPv6 (like 8+8 address rewrites on routers) we may not be able to success in IPv6, like IPv4 did. >Furthermore, we're discussing technology in its infancy. There is no >reason not to explore the possibilities. Remember, WE make the rules, so >we might as well look at all the options to the good ones. These >decisions will be with us for at LEAST a decade, let's make decisions we >can deal with. well, IPng effort was started year 1992 and now it's year 2001. i don't really agree with the "infancy" argument. you may notice that the email have went through IPv6-to-IPv4 translator to the mail list server (it may show the evidence on Received: lines). itojun From owner-multi6@ops.ietf.org Mon Jun 25 14:11:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23020 for ; Mon, 25 Jun 2001 14:11:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CpJo-000ON7-00 for multi6-data@psg.com; Wed, 20 Jun 2001 14:15:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15CpJn-000OMz-00 for multi6@ops.ietf.org; Wed, 20 Jun 2001 14:15:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 20 Jun 2001 14:15:15 -0700 Message-ID: <00b301c0f9ce$19bfe700$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Wed, 20 Jun 2001 14:15:15 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 20 Jun 2001 21:15:15.0645 (UTC) FILETIME=[19B81ED0:01C0F9CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why not bind the SK if it's globally unique? There is 1 SK, and multiple > GR's. Why not bind only the SK's and keep a table of valid GR's, so you > know that it is truly valid? We may be talking at cross purposes. What is the difference in your mind between binding to the SKs and GRs versus binding to the SK and keeping a table of GRs? > > This is the description of an SCTP association. This is almost exactly > SCTP through NAT. Yes. > My suggestion above takes a similar idea, but lets the > network do most of the multihoming instead of the protocol. Otherwise > you're basically talking about using NAT and SCTP together and calling it > something else, with a few small tweaks and dropping the heartbeat, etc. > Could you give me a clear explanation of your suggestion? I don't understand it. Also, regarding Add IP (another message from you about SCTP came in while I reply to this one...), you can't do this securely unless there is a trust relationship. Otherwise any spoofer can send a packet out of the blue with its GR and somebody else's SK and hijack the connection. Maybe this is what you mean by "bind to the SK only"---allow any GR to be used once the SK is established? The reason GxSE binds the whole list of addresses from the beginning is to prevent spoofing. If we have the luxury of establishing a secure relationship between both ends, then may as well use HIP. From owner-multi6@ops.ietf.org Mon Jun 25 14:13:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23079 for ; Mon, 25 Jun 2001 14:13:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EabW-000205-00 for multi6-data@psg.com; Mon, 25 Jun 2001 10:56:54 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15EabW-0001zj-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 10:56:54 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id MAA16888; Mon, 25 Jun 2001 12:57:04 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Mon, 25 Jun 2001 12:57:04 -0500 (CDT) From: "Jon (Taz) Mischo" To: Jun-ichiro itojun Hagino cc: RJ Atkinson , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <20010625164740.AB8FB7BB@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 26 Jun 2001, Jun-ichiro itojun Hagino wrote: > well, there are at least two. > draft-yu-simple-ipv6multihoming-01.txt > draft-ietf-ipngwg-ipv6-2260-01.txt We appreciate the reiteration of existing drafts, however, please keep in mind we are a young working group and want to do things RIGHT. Our charter is only our first charter, this may very well change. I would respectfully request that we stop talking about limiting the scope of the conversation, and wait until after the requirements phase to do so. The beauty of the requirements phase is that open discussions like these can produce new requirements we hadn't thought of before. Thank you, -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Mon Jun 25 14:13:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23095 for ; Mon, 25 Jun 2001 14:13:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Earw-0002XY-00 for multi6-data@psg.com; Mon, 25 Jun 2001 11:13:52 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15Earv-0002XS-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 11:13:51 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id NAA16936; Mon, 25 Jun 2001 13:13:58 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Mon, 25 Jun 2001 13:13:58 -0500 (CDT) From: "Jon (Taz) Mischo" To: Jun-ichiro itojun Hagino cc: RJ Atkinson , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <20010625175642.68ECC7BB@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 26 Jun 2001, Jun-ichiro itojun Hagino wrote: > >I understand how you feel, however, I feel rather strongly that we should > >do this the right way from the start. One of the biggest problems with > >NAT is that it was an afterthought, thus broke many things. We're not > >designing a protocol here, just ways to handle certain situations. > > i disagree about the "from the start" part. the deployment is already > started here and there. maybe this is because i'm in Japan, but > i feel it way too late to make any changes to the way routers/hosts > work. I work for Motorola in Advanced Network Technologies. We are painfully aware of v6, both in Japan and in cellular IP. > also, remember why GSE proposal was not integrated into IPv6 - > IPv6 is designed based on IPv4 experiences, and tries to benefit > from the success of IPv4. if we add too many fundamental design > changes into IPv6 (like 8+8 address rewrites on routers) > we may not be able to success in IPv6, like IPv4 did. Yes, I understand this, but a lot of things have changed in v4, and what we are trying to do here is make v6 better. v6 is not widely deployed. We are trying to design things that will work seamlessly, so it is a choice of whether or not to implement/when to implement. > >Furthermore, we're discussing technology in its infancy. There is no > >reason not to explore the possibilities. Remember, WE make the rules, so > >we might as well look at all the options to the good ones. These > >decisions will be with us for at LEAST a decade, let's make decisions we > >can deal with. > > well, IPng effort was started year 1992 and now it's year 2001. > i don't really agree with the "infancy" argument. > you may notice that the email have went through IPv6-to-IPv4 > translator to the mail list server (it may show the evidence on > Received: lines). This is multi6, not IPng, and multi6 is young. Furthermore, we have the chance to do things right instead of kludging them as we go along. My vote is for doing it right ahead of time. v6 is still very young. Anyone deploying it already knows there is still work being done on it and that some of this work may affect the future. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Mon Jun 25 14:15:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23129 for ; Mon, 25 Jun 2001 14:15:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EasI-0002Xs-00 for multi6-data@psg.com; Mon, 25 Jun 2001 11:14:14 -0700 Received: from flowpoint.procket.com ([209.140.237.1] helo=alpha-tli.procket.com) by psg.com with esmtp (Exim 3.16 #1) id 15EasF-0002XI-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 11:14:11 -0700 Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id LAA26471; Mon, 25 Jun 2001 11:13:33 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15159.32584.352666.330700@alpha-tli.procket.com> Date: Mon, 25 Jun 2001 11:13:28 -0700 To: Jun-ichiro itojun Hagino Cc: "Jon (Taz) Mischo" , RJ Atkinson , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <20010625175642.68ECC7BB@starfruit.itojun.org> References: <20010625175642.68ECC7BB@starfruit.itojun.org> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | also, remember why GSE proposal was not integrated into IPv6 - | IPv6 is designed based on IPv4 experiences, and tries to benefit | from the success of IPv4. if we add too many fundamental design | changes into IPv6 (like 8+8 address rewrites on routers) | we may not be able to success in IPv6, like IPv4 did. One of IPv4's biggest failures is its 'success failure' scenario. It is failing precisely because it has been so successful. If IPv6 does not address the routing architecture issues in IPv4, it is doomed to the exact same fate, at the exact same time. Change or die. It's that simple. Tony From owner-multi6@ops.ietf.org Mon Jun 25 14:46:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23827 for ; Mon, 25 Jun 2001 14:46:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EbNK-0003cv-00 for multi6-data@psg.com; Mon, 25 Jun 2001 11:46:18 -0700 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by psg.com with esmtp (Exim 3.16 #1) id 15EbNJ-0003cb-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 11:46:17 -0700 Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5PIjrx18218; Mon, 25 Jun 2001 11:45:53 -0700 (PDT) Received: from [171.70.84.50] (deering-office-mac.cisco.com [171.70.84.50]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAU56232; Mon, 25 Jun 2001 11:45:44 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: References: Date: Mon, 25 Jun 2001 11:45:48 -0700 To: "Jon (Taz) Mischo" From: Steve Deering Subject: Re: An idea: GxSE Cc: Jun-ichiro itojun Hagino , RJ Atkinson , multi6@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk I don't think it's useful at this stage to be arguing about whether or not this group can impose changes on existing IPv6 implementations. Rather: first, let's get the requirements and desirements agreed to, second let's identify solutions that would satisfy the requirements, and third, assuming there is more than one such solution, let's understand the nature and degree of change required by each solution (e.g., does it require changes to all routers? edge routers? host IPv6 layers? applications? nothing?), as an important input to the process of choosing a particular solution (or set of solutions). I thought we were supposed to be moving quickly to resolve the first step, but most of the email seems to be trying to prejudge the outcome of the second and third steps. Steve From owner-multi6@ops.ietf.org Mon Jun 25 14:49:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23897 for ; Mon, 25 Jun 2001 14:49:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EbQl-0003ko-00 for multi6-data@psg.com; Mon, 25 Jun 2001 11:49:51 -0700 Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by psg.com with esmtp (Exim 3.16 #1) id 15EbQk-0003jx-00; Mon, 25 Jun 2001 11:49:50 -0700 Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA08840; Mon, 25 Jun 2001 11:48:40 -0700 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA21166; Mon, 25 Jun 2001 11:47:46 -0700 Message-ID: <3B3785B4.111D2FE6@hursley.ibm.com> Date: Mon, 25 Jun 2001 13:40:52 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Randy Bush CC: multi6@ops.ietf.org Subject: Re: An idea: GxSE References: <20010625154512.773772A4B@orchard.arlington.ma.us> <3B376EBE.8ED2A12D@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush wrote: > > as we have no running code, i suggest we try to understand the needs, then > how they might be achieved, and then, and only then, can we say whether code > will need to change or not. > > considering the vast and pervasive v6 deployment to date as compared to its > expected lifetime, i suspect we can afford to get it right. Randy, I suggested some very precise requirements text to take account of the fact that there is a lot of running and shipped code in existing products that is simply not going to get rewritten that quickly. Like it or not, multi6 has to coexist with vanilla IPv6, and that generates its own set of requirements. Brian From owner-multi6@ops.ietf.org Mon Jun 25 15:21:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24706 for ; Mon, 25 Jun 2001 15:21:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Ebvw-0004lw-00 for multi6-data@psg.com; Mon, 25 Jun 2001 12:22:04 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 15Ebvv-0004lp-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 12:22:03 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f5PJMdH01459; Mon, 25 Jun 2001 21:22:39 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 25 Jun 2001 21:22:01 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Daniel Senie cc: multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <5.1.0.14.2.20010625124009.03d48130@mail.amaranth.net> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 25 Jun 2001, Daniel Senie wrote: > >There are quite a few things we can do to improve NAT: > >- add a "NAT control protocol" so applications can instruct the NAT box to > > enable/disable certain features and find out what their "real" address is > Please go read the RSIP documents. A pointer or the full name would be helpful. > There are a LOT of problems with this, > not the least of which is there may be multiple layers of NAT between a > workstation and the global address space. It is quite problematic to deal > with these cases, and they ARE common. I'm very tempted to say that people with such a setup are asking for whatever problems they are getting... But I'm not. If NAT is ever to become a serious alternative to real connectivity, there is a lot to be done. If a control protocol makes things better for a lot of people, I think it's a good thing. Too bad for those who use setups that are even more complex. They should just keep doing things the way they are now. > And since NAT doesn't provide a reliable end-point address in some cases, > there's no way to put servers behind it. Or peer-to-peer neworking > applications. Obviously that would be just about the first requirement for any serious multihoming alternative. I don't think it's worth the effort to think about outgoing-only multihoming. Iljitsch From owner-multi6@ops.ietf.org Mon Jun 25 15:22:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24722 for ; Mon, 25 Jun 2001 15:22:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Ebwh-0004nT-00 for multi6-data@psg.com; Mon, 25 Jun 2001 12:22:51 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15Ebwh-0004n7-00; Mon, 25 Jun 2001 12:22:51 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id OAA17055; Mon, 25 Jun 2001 14:22:58 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Mon, 25 Jun 2001 14:22:58 -0500 (CDT) From: "Jon (Taz) Mischo" To: Brian E Carpenter cc: Randy Bush , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <3B3785B4.111D2FE6@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 25 Jun 2001, Brian E Carpenter wrote: > Randy, I suggested some very precise requirements text to take account of the > fact that there is a lot of running and shipped code in existing products that > is simply not going to get rewritten that quickly. Like it or not, multi6 > has to coexist with vanilla IPv6, and that generates its own set of > requirements. Brian, if we can make something like GxSE work with vanilla v6, however, that should satisfy everyone. Instead of clobbering the discussion, I think we should expand it. There must be a happy medium. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Mon Jun 25 15:30:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24917 for ; Mon, 25 Jun 2001 15:30:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Ec4U-00055x-00 for multi6-data@psg.com; Mon, 25 Jun 2001 12:30:54 -0700 Received: from [63.108.254.91] (helo=gnat.inet.org) by psg.com with esmtp (Exim 3.16 #1) id 15Ec4T-00054g-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 12:30:53 -0700 Received: from mosquito.inet.org (rja-laptop [10.30.34.139]) by gnat.inet.org (Postfix) with ESMTP id 7784D8266E; Mon, 25 Jun 2001 15:30:17 -0400 (EDT) Message-Id: <5.1.0.14.2.20010625152352.00a34600@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Jun 2001 15:26:21 -0400 To: Iljitsch van Beijnum From: RJ Atkinson Subject: Re: An idea: GxSE Cc: multi6@ops.ietf.org In-Reply-To: References: <20010625154512.773772A4B@orchard.arlington.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 12:36 25/06/01, Iljitsch van Beijnum wrote: >Unless I overlook something there are basically four ideas to keep the growth of the routing table as a result from multihoming to a minimum: > >1. NAT and other address rewriting ideas. Pro: works today. Con: NAT box is > a single point of failure, sessions don't survive address change. Also Con: ESP/AH don't work through the NAT. Transparency is visibly below desired levels. >3. Geo addressing. Pro: no (new) software necessary, works in IPv4. Con: > routing table effect may be as little as one order of magnitude. It isn't clear to me that this works in either IPv4 or IPv6. If the IDR scaling improvements are not significant, it isn't a sufficient improvement (IMHO). >4. More efficient routing information encoding (such as bitmaps). Pro: same > hardware can accomodate several orders of magnitude larger routing table. > Con: many things: new protocol versions, new software, etc. If this were sufficient by itself, then at least some of the vocal routing folks here would not be as vocal as they are being, IMHO. Ran From owner-multi6@ops.ietf.org Mon Jun 25 15:31:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24985 for ; Mon, 25 Jun 2001 15:31:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Ec5u-00058b-00 for multi6-data@psg.com; Mon, 25 Jun 2001 12:32:22 -0700 Received: from [63.108.254.91] (helo=gnat.inet.org) by psg.com with esmtp (Exim 3.16 #1) id 15Ec5t-00057D-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 12:32:22 -0700 Received: from mosquito.inet.org (rja-laptop [10.30.34.139]) by gnat.inet.org (Postfix) with ESMTP id A8FED8266E; Mon, 25 Jun 2001 15:31:50 -0400 (EDT) Message-Id: <5.1.0.14.2.20010625152647.00a33d20@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Jun 2001 15:27:55 -0400 To: Jun-ichiro itojun Hagino From: RJ Atkinson Subject: Re: An idea: GxSE Cc: multi6@ops.ietf.org In-Reply-To: <20010625164740.AB8FB7BB@starfruit.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 12:47 25/06/01, Jun-ichiro itojun Hagino wrote: >> Myself, I doubt that any approach that is operationally >>practical and resolves the IDR routing table issues caused by >>multi-homing can be found that requires "no new code". I'd be >>tickled pink if someone demonstrated such an approach, but haven't >>heard about one here so far... > > well, there are at least two. > draft-yu-simple-ipv6multihoming-01.txt > draft-ietf-ipngwg-ipv6-2260-01.txt Have read those. I don't believe either of these drafts "resolves the IDR routing table issues caused by multi-homing", and that's just for openers. Ran From owner-multi6@ops.ietf.org Mon Jun 25 15:37:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25109 for ; Mon, 25 Jun 2001 15:37:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EcBV-0005MY-00 for multi6-data@psg.com; Mon, 25 Jun 2001 12:38:09 -0700 Received: from [63.108.254.91] (helo=gnat.inet.org) by psg.com with esmtp (Exim 3.16 #1) id 15EcBU-0005Kv-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 12:38:08 -0700 Received: from mosquito.inet.org (rja-laptop [10.30.34.139]) by gnat.inet.org (Postfix) with ESMTP id D632E8266E; Mon, 25 Jun 2001 15:37:36 -0400 (EDT) Message-Id: <5.1.0.14.2.20010625152857.00a32760@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Jun 2001 15:33:41 -0400 To: Jun-ichiro itojun Hagino From: RJ Atkinson Subject: Re: An idea: GxSE Cc: multi6@ops.ietf.org In-Reply-To: <20010625175642.68ECC7BB@starfruit.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 13:56 25/06/01, Jun-ichiro itojun Hagino wrote: > also, remember why GSE proposal was not integrated into IPv6 GSE was not integrated due to politics, pure and simple. Lets please try to make technical decisions over here in multi6, rather than repeat past political mistakes. > IPv6 is designed based on IPv4 experiences, and tries to benefit > from the success of IPv4. if we add too many fundamental design > changes into IPv6 (like 8+8 address rewrites on routers) > we may not be able to success in IPv6, like IPv4 did. Itojun, 8+8 rewrites in a border router at 1/10 Gbps line speed aren't worrying the major router vendors, AFAIK. Certainly it doesn't cause me to lose sleep at night. However, we haven't yet decided whether we want to take that approach or not. It IS sensible to try to sort out what problem(s) we are trying to solve up front, without closing doors. Then we can try to sort things out among various alternative approaches. Stopping the discussion prematurely will guarantee failure, however. Ran rja@inet.org From owner-multi6@ops.ietf.org Mon Jun 25 15:39:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25150 for ; Mon, 25 Jun 2001 15:39:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EcCs-0005OX-00 for multi6-data@psg.com; Mon, 25 Jun 2001 12:39:34 -0700 Received: from openbsd-0.lcs.mit.edu ([18.26.4.157] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.16 #1) id 15EcCr-0005OR-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 12:39:33 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id EE5FF7BB; Tue, 26 Jun 2001 04:36:59 +0900 (JST) To: RJ Atkinson Cc: multi6@ops.ietf.org In-reply-to: rja's message of Mon, 25 Jun 2001 15:27:55 -0400. <5.1.0.14.2.20010625152647.00a33d20@10.30.15.2> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: An idea: GxSE From: Jun-ichiro itojun Hagino Date: Tue, 26 Jun 2001 04:36:59 +0900 Message-Id: <20010625193659.EE5FF7BB@starfruit.itojun.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk >> well, there are at least two. >> draft-yu-simple-ipv6multihoming-01.txt >> draft-ietf-ipngwg-ipv6-2260-01.txt > Have read those. I don't believe either of these drafts >"resolves the IDR routing table issues caused by multi-homing", >and that's just for openers. they don't require us to inject more-specific routes to worldwide routing table, so they should be more routing-table-size friendly than currently practiced IPv4 multihomnig. itojun From owner-multi6@ops.ietf.org Mon Jun 25 15:47:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25408 for ; Mon, 25 Jun 2001 15:47:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EcKc-0005h2-00 for multi6-data@psg.com; Mon, 25 Jun 2001 12:47:34 -0700 Received: from mx1out.umbc.edu ([130.85.253.51]) by psg.com with esmtp (Exim 3.16 #1) id 15EcKb-0005gu-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 12:47:33 -0700 Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx1out.umbc.edu (8.11.3/8.11.3) with ESMTP id f5PJlSR28458 for ; Mon, 25 Jun 2001 15:47:28 -0400 (EDT) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id PAA12952948 for ; Mon, 25 Jun 2001 15:47:27 -0400 (EDT) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Mon, 25 Jun 2001 15:47:27 -0400 From: Vijay Gill X-X-Sender: To: Subject: Re: An idea: GxSE In-Reply-To: <20010625193659.EE5FF7BB@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 26 Jun 2001, Jun-ichiro itojun Hagino wrote: > >> draft-yu-simple-ipv6multihoming-01.txt > they don't require us to inject more-specific routes to worldwide > routing table, so they should be more routing-table-size friendly > than currently practiced IPv4 multihomnig. This one at least, has been extensively commented upon in the IPNG wg mailing list by myself and ben black, among others. A check on the ipng archives might prove to be useful. fyi /vijay From owner-multi6@ops.ietf.org Mon Jun 25 15:47:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25409 for ; Mon, 25 Jun 2001 15:47:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EcKd-0005h9-00 for multi6-data@psg.com; Mon, 25 Jun 2001 12:47:35 -0700 Received: from garlic.amaranth.net ([216.235.243.195]) by psg.com with esmtp (Exim 3.16 #1) id 15EcKc-0005gw-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 12:47:34 -0700 Received: from yarrow.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f5PJlVl32559 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Mon, 25 Jun 2001 15:47:32 -0400 Message-Id: <5.1.0.14.2.20010625152416.03ccb100@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Jun 2001 15:35:02 -0400 To: Iljitsch van Beijnum From: Daniel Senie Subject: Re: An idea: GxSE Cc: multi6@ops.ietf.org In-Reply-To: References: <5.1.0.14.2.20010625124009.03d48130@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 03:22 PM 6/25/01, Iljitsch van Beijnum wrote: >On Mon, 25 Jun 2001, Daniel Senie wrote: > > > >There are quite a few things we can do to improve NAT: > > > >- add a "NAT control protocol" so applications can instruct the NAT box to > > > enable/disable certain features and find out what their "real" > address is > > > Please go read the RSIP documents. > >A pointer or the full name would be helpful. Go read all the NAT stuff at: http://www.ietf.org/html.charters/nat-charter.html all of the documents are listed out there. The RSIP documents are, I believe, going to be published as Experimental. I'm not sure why they haven't already been published as such. > > There are a LOT of problems with this, > > not the least of which is there may be multiple layers of NAT between a > > workstation and the global address space. It is quite problematic to deal > > with these cases, and they ARE common. > >I'm very tempted to say that people with such a setup are asking for whatever >problems they are getting... But I'm not. > >If NAT is ever to become a serious alternative to real connectivity, there is >a lot to be done. If a control protocol makes things better for a lot of >people, I think it's a good thing. Too bad for those who use setups that are >even more complex. They should just keep doing things the way they are now. There are many ISPs in the world who are using NAT to cover all their customers. Any customer who then needs to hook up more than one computer gets to do another level of NAT. Is this a bad idea? Sure. However, if RSIP or similar go forward, it will likely be in that environment. Will this happen again in the IPv6 world? Unclear. I suspect, though, that having NAT at multiple levels will not disappear. > > And since NAT doesn't provide a reliable end-point address in some cases, > > there's no way to put servers behind it. Or peer-to-peer neworking > > applications. > >Obviously that would be just about the first requirement for any serious >multihoming alternative. Agree. > I don't think it's worth the effort to think about >outgoing-only multihoming. Agree again. There are already products in the marketplace for IPv4 which handle outgoing-only multihoming without the involvement of upstream ISPs. These are useful products for those users who can live with the limitations, but not worth considering for multi6. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-multi6@ops.ietf.org Mon Jun 25 16:48:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26627 for ; Mon, 25 Jun 2001 16:48:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EdHn-0007dA-00 for multi6-data@psg.com; Mon, 25 Jun 2001 13:48:43 -0700 Received: from arpa.it.uc3m.es ([163.117.139.120]) by psg.com with esmtp (Exim 3.16 #1) id 15EdHl-0007cy-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 13:48:41 -0700 Received: from avispa (avispa.it.uc3m.es [163.117.139.178]) by arpa.it.uc3m.es (8.9.3/8.9.3) with SMTP id WAA28487; Mon, 25 Jun 2001 22:48:32 +0200 From: "marcelo" To: Cc: , , Subject: Survey on proposed IPv6 multi-homing mechanisms Date: Mon, 25 Jun 2001 22:48:36 +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.50.4133.2400 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi, We have been working on a survey of proposals related to IPv6 multi-homing. We think that this could be a good input for a discussion about which of these ideas can be valuable, and need to be further developed. We have included all the mechanisms that we have found. If there are other mechanisms, please let us know. We have also includes some advantages and concerns about the mechanisms, but we think that discusion will really disclose much more points. After our study, we feel that could be interesting to develop solution presented as "Preserving active TCP sessions on multi-homed IPv6 networks", what do you feel about it? We hope you enjoy it, m M. Bagnulo A. Garcia-Martinez A. Azcorra D. Larrabeiti Universidad Carlos III de Madrid Survey on proposed IPv6 multi-homing network level mechanisms Introduction This article presents proposed solutions and tools related to multi-homing. All presented proposals respect actual IPv6 routing architecture and current ISP address aggregation scheme, in particular, avoiding route injection to the DFZ. Besides, only network and transport level solutions are introduced, meaning that application level solutions are intentionally excluded. The aim of this study is to provide a compilation of the proposed solutions to serve as an input to multi6 working group discussion. Index 1. IPv6 multi-homing with route aggregation.........................1 2. IPv6 multi-homing support at site exit routers...................3 3. Multi-homing with router renumbering.............................4 4. Preserving active TCP sessions on Multi-homed networks...........6 5. Mobility mechanisms..............................................7 6. Routing headers usage............................................8 7. Routing support for IPv6 multi-homing............................9 1. IPv6 multi-homing with route aggregation. The solution presented in [YU] is intended to achieve the following objectives: - Redundancy provision in case of connection failure, in order to guarantee that the multi-homed site remains on line even if there is only one connection working properly. - Load sharing among available connections, so that both inbound and outbound traffic is balanced using the existing providers. - Simple management. Solution mechanism: ______________________________ | Internet | |______________________________| | | link1 | link5 | link2 ISPA--------------------- ISPB \ / link3 \______________________/ link4 | Multi-homed site | | PrefA:Prefsite::/n | |______________________| Figure 1: Multi-homing with route aggregation Survey on multi-homing mecanisms 2 In the topology depicted in Figure 1, the multi-homed site is connected to the Internet through two different ISPs (ISPA and ISPB). Besides, the considered site has obtained global addresses only from ISPA, which will be called primary ISP, so that the addresses contain PrefA (ISP based address aggregation is used). Note that in this solution, the multi-homed site needs only one global prefix. The propagation of routing information would be as follows: - The site propagates PrefA:Prefsite::/n to ISPA and ISPB through link3 and link4 respectively. - ISPB propagates PrefA:Prefsite::/n to ISPA through link5. Note that ISPB does NOT propagates routing information about PrefA:Prefsite::/n to the Internet. - ISPA propagates PrefA::/nA to the Internet through link1. With the described routing configuration, inbound traffic (traffic from the Internet to the site) will be routed towards ISPA through link1. Then ISPA performs load balancing through link3 and link5 (and therefore in this case, also through ISPB and link4). Outbound traffic (traffic from the site to the Internet) can be forwarded through ISPA (link3) or ISPB (link4) depending on the routing configuration of the site. In the case of failure, connectivity would be granted on the following situations: - If link3 fails, ISPA routes all traffic coming from the Internet towards the site through ISPB (link5 and then link4). Outbound traffic generated on site is routed through link4 to ISPB. - If link4 fails, ISPA does not route traffic to the site through ISPB (link5) so that all traffic is transmitted using link3. Traffic from the site to the Internet is exclusively routed through ISPA (link3). Mechanism evaluation Advantages - Neither new protocol nor new mechanism are needed, facilitating deployment. - Several global addresses per interface are no longer needed to obtain the benefits of the multi-homing architecture, which simplifies management on the site. - Provides fault tolerance if one of the links (link3 or link4) connecting to the ISP fails. - Preserves established TCP connections through link failure - Allows load sharing, provided that local policies are capable to define which exit link to use. Concerns - Primary ISP is critical because: Its link to the Internet (link1) is the only used for inbound traffic, The mechanisms does not provide fault tolerance neither in case of primary ISP failure nor for Primary ISP Internet link failure. Another critical task that Primary ISP must implement is load sharing, deciding which link to use for inbound traffic. - The tasks that the primary ISP must complete imply a more complex ISP administration. - The mechanism is more efficient when a direct connection between ISPA and ISPB (link5) exists. If there is no such connection, more routing information has to be propagated, intermediate ISPs are involved, and Survey on multi-homing mecanisms 3 less effective aggregation is achieved. - The mechanism requires coordination between ISPs, which may conflict with their commercial interests. Moreover, additional commercial issues may arise from the fact that there are two different roles appear, primary ISP and the rest. - Even though the mechanism allows load sharing, it does not provide any tool to perform ISP selection. Since the outbound link depends on site policies and the inbound link is determined by primary ISP, it is difficult to provide a coherent path for both directions of a given connection. - The mechanism to achieve load balance in the primary ISP for inbound traffic is not specified. 2. IPv6 multi-homing support at site exit routers. This mechanism is originally presented in [BATES] and further detail is given in [ITOJUN]. The intended goal of the mechanism is to maintain multi-homed site connectivity with the Internet even when some of the exit links are down. [ITOJUN] explicitly expresses that this mechanism is not intended to provide link selection nor load balancing. Solution mechanism The solution is presented in the illustrated scenario: +----+ +----+ |ISPA|____________________ |ISPB| |BRA | __________________\___|BRB | +----+ / \ +----+ | /link3 link4 \ | link1 | / \ | link2 _|_/_________________________\__|_ | RA RB | | Multi-homed site | |PrefA:Prefsite PrefB:Prefsite| |__________________________________| Figure 2: Multi-homing support at exit site routers In the configuration above, the multi-homed site is connected to the Internet through 2 ISPs (ISPA and ISPB) using link1 and link2 respectively. Each of the ISP has delegated an address space to the site: ISPA has delegated PRefA:Prefsite::/nA+n and ISPB has delegated PrefB:Prefsite::/nB+n. Besides, secondary links (link3 and link4) are established between the site and the ISPs. Link3 bonds the site exit router connecting with ISPA (RA) with the border router of ISPB (BRB). Link4 bonds the site exit router connecting with ISPB (RB) with the border router of ISPA (BRA). Secondary links are usually implemented as IP over IP tunnels. This tunnels may be built over existing physical links (link1 and link2) although the usage of additional physical links is recommended. In normal conditions, secondary links are advertised by the routing protocol with a very low priority, so that primary links (link1 and link2) are used. In case of failure, primary links are no longer Survey on multi-homing mecanisms 4 advertised so secondary links become a valid option for the routers. Mechanism evaluation Advantages - Provides fault tolerance for ISP connecting link failure. - Preserves established TCP connections through link failure. - There is no need for new protocols or mechanisms. Concerns - Does not provide fault tolerance in case of ISP failure. - Does not provide tools for ISP selection for load sharing. - In case of long term failure, an additional mechanism is required for preventing the usage of the secondary link. This implies some mechanism to stop the usage of crashed ISP addresses as source address of outbound packets. - Implies more complex management due to the need of several global addresses per interface requiring the use of several ISPs. Another source of management complexity is the need of tunnel configuration. 3. Multi-homing with router renumbering This proposal is described in [DUPONT]. It basically consists of the usage of Router Renumbering [CRAWFORD] and Router Advertising protocols to deprecate addresses in case of ISP failure. __________________________________________ | Internet | | | |__________________________________________| | | | | +----+ +----+ |ISPA| |ISPB| |BRA | |BRB | +----+ +----+ | | link1 | | link2 __|____________________________|__ | RA RB | | | | | | ------------------------------- | | | | | RC | | | | Multi-homed site | |PrefA:Prefsite PrefB:Prefsite| |__________________________________| Figure 3: Multi-homing with router renumbering Survey on multi-homing mecanisms 5 In the depicted topology the multi-homed site obtains Internet connectivity using two ISPs (ISPA and ISPB). Each one of the ISPs has delegated an address space to the site, PrefA:Prefsite::/n and PrefB:Prefsite::/n respectively. In normal conditions, any device in the site that need to obtain internet access through both ISPs needs one global address of each address space, so that every interface is configured with at least two global addresses. Note that the inbound route is determined by the address used to refer to such device. In case of failure, the mechanism works as follows: Suppose that ISPA crashes. When an external host needs to communicate with any device of the site, it will query the DNS. The DNS will provide at least two addresses, as we stated before. If the ISPA delegated address (PrefA:Prefsite::host) is used, communication will fail, forcing the usage of the other address. When an internal host needs to establish a communication with an external host, internal routing configuration will course the outbound packet towards the ISP which is working properly. However if the packet source address belongs to ISPA address space, communication will not be established, because retuning packets will be routed towards the crashed ISP (ISPA). So, to ensure connectivity it is imperative to avoid the usage of addresses delegated by the crashed ISP, ISPA in our example. This can be achieved using the Router Advertising protocol and Router Renumbering protocol. In our site, the exit router connecting with ISPA (RA) would detect the failure and immediately would send a router advertising in order to deprecate ISPA delegated addresses. It would also use the Router Renumbering protocol to propagate the information about deprecation to other routers, such as RC, so that this addresses will not be used in any new connection. Mechanism evaluation Advantages - Provides stable configuration in case of long term ISP failure. Note that it provides ISP fault tolerance, not only link fault tolerance. - There is no need for any new protocol or mechanism. Concerns - It does not preserve established TCP connections. - It does not provide tools for ISP selection for load sharing purposes. - Several global addresses per interface are needed in order to seize multi-homing benefits, leading to management complexity. Observation: Multi-homing support at exit site routers and Multi-homing with router renumbering mechanisms can be used together in order to provide a more complete solution. If both mechanisms are used, short term failures can be managed using tunnels, while for long term failures the router renumbering mechanism is used. Survey on multi-homing mecanisms 6 4. Preserving active TCP sessions on Multi-homed networks. A completely different approach is introduced in [TATTAM], which is based on the idea that most IPv6 interfaces will have several IP addresses assigned, specially in a multi-homed environment. When a TCP connection is established, both ends of the connection should be identified by a set of addresses, instead of only one address as it is done today. In order to do that, when a TCP connection is established, each end identifies itself with a set of valid addresses. The application to a multi-homing scenario would be as follows: Suppose that the multi-homed site has two ISP (ISPA and ISPB), and both of them have delegated an address space to the site, PrefA:Prefsite::/n and PrefB:Prefsite::/n respectively. Any host in the site that intends to use both ISPs needs al least two global addresses, PrefA:Prefsite::host and PrefB:Prefsite::host. When this host establishes a TCP connection with any other host in the Internet, it identifies itself with a set of addresses which is composed by PrefA:Prefsite::host and PrefB:Prefsite::host. If any of the ISPs crashes, the connection can survive just using the address of the other ISP. Originally, in [TATTAM], it is proposed that the valid set of addresses identifying a host in a TCP connection is exchanged during TCP three-way handshake, using TCP options. Afterwards, in [TOKYO] the usage of an IPv6 destination option was proposed. This overcomes the 40 bytes limit of TCP options. Mechanism evaluation Advantages - Provides complete fault tolerance including preservation of active TCP connections, meaning that if there is an available path, connectivity is ensured. - There is no need for changes in network devices, because it is a host-based solution Concerns - Introduces modifications in the protocol, IP or TCP. Furthermore, in order to provide a working solution, changes are needed in both hosts involved in the connection, not only the host belonging to the multi-homed site. - It does not provide any tool for load sharing or ISP selection. - This mechanism could have impact on security issues, like connection hijacking, that must be considered on mechanism design. - Basic solution is limited to TCP traffic only 5. Mobility mechanisms Another proposal presented in [DUPNOT] is based in the use of IP mobility mechanisms. The main idea is to use the care-of-address assignation mechanism to switch between delegated addresses in case of failure. Suppose that there is an established communication between Survey on multi-homing mecanisms 7 hostA belonging to the multi-homed site and hostB, somewhere in the Internet, as shown in figure 4. ___________________________________________ | Internet | | hostB | |___________________________________________| | | | | +----+ +----+ |ISPA| |ISPB| |BRA | |BRB | +----+ +----+ | | link1 | | link2 __|____________________________|___ | RA RB | | | | | | ------------------------------- | | | | | hostA | | PrefA:Prefsite:hostA | | PrefB:Prefsite:hostA | | | |___________________________________| Figure 4: Mobility mechanisms The established connection is being routed through ISPA and PrefA:Prefsite:hostA is used. If ISPA fails, the described steps are followed in order to preserve communication: - HostA packets contain the home address destination option with PrefA:Prefsite:hostA and PrefB:Prefsite:hostA as source address, so that for every device on the path source address is PrefB:Prefsite:hostA and only hostB replaces this source address by PrefA:Prefsite:hostA. - HostA sends a binding update containing PrefB:Prefsite:hostA as a care-of address. Note that that authentication header is needed in this packet. - HostB sends a binding acknowledgement. This packet and all next packets are sent with PrefA:Prefsite:hostA as final destination (included in a routing header) and PrefB:Prefsite:hostA as next destination (included as destination address). Consequently, all packets are sent towards HostA using ISPB, and address "translation" is done when packets reach HostA. Mechanism Evaluation: Advantages: - The mechanism provides complete fault tolerance. - It uses existing protocols. - It allows ISP selection for load sharing. Survey on multi-homing mecanisms 8 Concerns - Needs Mobile IP implementation on destination host. So, modifications in external hosts are needed to achieve internal multi-homing. - Mobile IP security mechanisms impose the use of authentication header, raising complexity. 6. Routing headers usage A mechanism intended to force routing through a specific ISP in multi-homed sites is suggested in [JOHNSON]. The main idea is to include a routing header with an intermediate anycast address identifying selected ISP routers, in order to force the packet path through the chosen ISP. Another approach for ISP selection is site exit router selection, instead of ISP router selection. When different routers support ISP connections, exit router selection can be done using a Routing Header that includes a site-local address assigned to one of the router interfaces. In the case that more than one exit router were connected to the same ISP, this address would be assigned to all the connecting routers, becoming an anycast address. If the packets are routed to a single exit router, ISP selection can be implemented locally in the border device. Note that supporting both ISP connections on a single router introduces a single point of failure, which precludes the fault tolerance ability pursued in multi-homing architectures. There are some differences between the two approaches, that wiil be presented next. In the first case, the routing header was used to force a path including the ISP routers anycast address; as a consequence, processing of the routing header requires ISP routing resources. In the second case, the processing of the routing header is done by the site exit router, which presents some benefits: Improved scalability: as one ISP connects many sites with the Internet, interpretation of routing headers could be a heavy task. If it is done at site exit routers scalability is preserved. ISP independence: There is no need for ISP cooperation, such as support for the all routers anycast address in the ISP network. Advantages - It is the only proposed method to explicit ISP selection by hosts. This enables ISP selection mechanisms based on other criteria than link availability. - This solution is based in existing protocols, so it is fast and easy to implement and deploy. - This solution is implemented completely at network level granting performance. Concerns. - Overhead of routing headers. - Some host modifications are needed in order to include the appropriate routing headers. - Management of information, such as routers address could be high. Survey on multi-homing mecanisms 9 7. Routing support for IPv6 multi-homing A more specific multi-homing issue, related to the configuration shown in figure 4, is addressed in [BRAGG]. ___________________________________________ | Internet | | | |___________________________________________| | | | | | | +----+ +----+ |TLA1| |TLA2| |BRT1| |BRT2| +----+ +----+ | | link1 | TLA1::/16 link2 | TLA2::/16 | | +----+ +----+ |NLA1| |NLA2| |BRN1| |BRN2| +----+ +----+ | | link3 | TLA1:NLA1::/16+n1 link4| TLA2:NLA2::/16+n2 __|____________________________|___ | RA RB | | | | Multi-homed site | |T1:N1:Prefsite::/16+n1+n | |T2:N2:Prefsite::/16+n2+n | |___________________________________| Figure 5: Routing support for multi-homing In the above configuration, the multi-homed site is connected to two ISPs. Each one of the connecting ISP belongs to a different TLA (TLA1 and TLA2). Each ISP delegates a site prefix: T1:N1:Prefsite::/16+n1+n and T2:N2:Prefsite::/16+n2+n. Routing information is propagated as described in figure 5, so TLA1 border router (BRT1) propagates TLA1::/16 to NLA1 through link1, TLA2 border router (BRT2) propagates TLA2::/16 to NLA2 through link2, NLA1 border router (BRN1) propagates TLA1:NLA1::/16+n1 to the site through link3, NLA2 border router (BRN2) propagates TLA2:NLA2:/16+n2 to the site through link4. Suppose that link1 fails. This has no relevant impact in inbound traffic, because after trying without success with T1:N1:Prefsite::host address, external hosts will try with T2:N2:Prefsite::host and connection will be established. The main problem appears when an internal host initiates a connection with an external host. If the internal host uses T1:N1:Prefsite::host as source address, returning packets of this connection have no available inbound path. In order to avoid the presented behaviour, the Survey on multi-homing mecanisms 10 idea is to propagate TLA reachability information besides NLA reachability information through link3 and link4. In this case and in normal conditions, NLA1 border router (BRN1) propagates TLA1:NLA1::/16+n1 and TLA1::/16 to the site through link3, NLA2 border router (BRN2) propagates TLA2:NLA2:/16+n2 and TLA2::/16 to the site through link4. If link1 fails, NLA1 border router (BRN1) only propagates TLA1:NLA1::/16+n1 to the site through link3, so internal routers know that the Internet is not reachable through NLA1. This information can be used by the source address selection algorithm of the internal host to avoid the usage of those addresses as source address. References [YU]J. Yu, "IPv6 multi-homing with route aggregation", draft-ietf-ipng-ipv6multihome-with-aggr-00.txt, 11/1999 [BATES] T. Bates, "Scalable support for multi-homed multi-provider connectivity", RFC2260, 1/1998 [ITOJUN]Jun-ichiro Hagino, "IPv6 multi-homing support at site exit routers", draft-ietf-ipngwg-ipv6-2260-01.txt, 4/2001 [DUPONT] F. Dupont, "Multihomed routing domain issues", draft-ietf-ipngwg-multi-isp-00,txt, 9/1999 [CRAWFORD] M. Crawford, "Router Renumbering for IPv6", RFC 2894, 8/2000 [TATTAM] P. Tattam, "Preserving active TCP sessions on Multi-homed networks", 9/1999 [TOKYO] IPng working group minutes/Tokyo meeting, 1999 [BRAGG] N. Bragg, "Routing support for IPv6 multi-homing", draft-bragg-ipv6-multihoming-00.txt, 11/2000 [JOHNSON] Johnson, D., Deering, S.: RFC 2526 - Reserved IPv6 Subnet Anycast Addresses. March 1999. Author´s addrsses. Marcelo Bagnulo Departamento de Ingenieria Telematica Universidad Carlos III de Madrid Av. Universidad 30 - 28911 LEGANES (MADRID) SPAIN Email: marcelo@it.uc3m.es Alberto Garcia-Martinez Departamento de Ingenieria Telematica Universidad Carlos III de Madrid Av. Universidad 30 - 28911 LEGANES (MADRID) SPAIN Email: alberto@it.uc3m.es Arturo Azcorra Departamento de Ingenieria Telematica Universidad Carlos III de Madrid Av. Universidad 30 - 28911 LEGANES (MADRID) SPAIN Email: azcorra@it.uc3m.es Survey on multi-homing mecanisms 11 David Larrabeiti Departamento de Ingenieria Telematica Universidad Carlos III de Madrid Av. Universidad 30 - 28911 LEGANES (MADRID) SPAIN Email: dlarra@it.uc3m.es From owner-multi6@ops.ietf.org Tue Jun 26 00:07:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06877 for ; Tue, 26 Jun 2001 00:07:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Ejjc-000LtS-00 for multi6-data@psg.com; Mon, 25 Jun 2001 20:41:52 -0700 Received: from www.bit-net.com ([208.146.132.4] helo=mail.users.bit-net.com) by psg.com with smtp (Exim 3.16 #1) id 15Ejjb-000LtM-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 20:41:51 -0700 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA06594; Mon, 25 Jun 2001 23:41:40 -0400 Date: Mon, 25 Jun 2001 23:41:40 -0400 (EDT) From: Jim Bound To: "Jon (Taz) Mischo" Cc: Jun-ichiro itojun Hagino , RJ Atkinson , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk In the spirit of fairness to Itojun. How can we ask him to not use the charter as a guideline? Is that not telling the chairs and ADs we are ignoring him. I do think we need to keep an open mind and very open ears and I personally think GxSE has merit. But we do need some guidelines if we are to ship an initial recommendation within a reasonable time for the IPv6 market, where deployment is going to happen even with the bad economic news, except in the U.S. in the commercial sector for awhile. The rest of the world wants it yesterday. So we do that that immediate v6 multihoming to deal with immediately if we can. Itojun has proposed some ideas and I think Ohta San that I think we could do to alleviate some of the pain for that early deployment. So I think we need to check out Itojun's and others work where it can solve a problem in the short term per the charter. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Mon, 25 Jun 2001, Jon (Taz) Mischo wrote: > On Tue, 26 Jun 2001, Jun-ichiro itojun Hagino wrote: > > > well, there are at least two. > > draft-yu-simple-ipv6multihoming-01.txt > > draft-ietf-ipngwg-ipv6-2260-01.txt > > We appreciate the reiteration of existing drafts, however, please keep in > mind we are a young working group and want to do things RIGHT. Our > charter is only our first charter, this may very well change. I would > respectfully request that we stop talking about limiting the scope of the > conversation, and wait until after the requirements phase to do so. The > beauty of the requirements phase is that open discussions like these can > produce new requirements we hadn't thought of before. > > Thank you, > -Taz > > -- > "Be liberal in what you accept, > and conservative in what you send." > --Jon Postel (1943-1998) RFC 1122, October 1989 > > From owner-multi6@ops.ietf.org Tue Jun 26 00:07:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06888 for ; Tue, 26 Jun 2001 00:07:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Ejt5-000MBP-00 for multi6-data@psg.com; Mon, 25 Jun 2001 20:51:39 -0700 Received: from www.bit-net.com ([208.146.132.4] helo=mail.users.bit-net.com) by psg.com with smtp (Exim 3.16 #1) id 15Ejt4-000MBI-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 20:51:38 -0700 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA06133; Mon, 25 Jun 2001 23:51:33 -0400 Date: Mon, 25 Jun 2001 23:51:33 -0400 (EDT) From: Jim Bound To: "Jon (Taz) Mischo" Cc: Brian E Carpenter , Randy Bush , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk could you or Paul take a stab at taking GxSE and extracting the reqs its solves and we an put those in our reqs definition with other reqs. I do think it wise we have reqs and then solutions. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Mon, 25 Jun 2001, Jon (Taz) Mischo wrote: > On Mon, 25 Jun 2001, Brian E Carpenter wrote: > > > Randy, I suggested some very precise requirements text to take account of the > > fact that there is a lot of running and shipped code in existing products that > > is simply not going to get rewritten that quickly. Like it or not, multi6 > > has to coexist with vanilla IPv6, and that generates its own set of > > requirements. > > Brian, if we can make something like GxSE work with vanilla v6, however, > that should satisfy everyone. Instead of clobbering the discussion, I > think we should expand it. There must be a happy medium. > > -Taz > > -- > "Be liberal in what you accept, > and conservative in what you send.." > --Jon Postel (1943-1998) RFC 1122, October 1989 > > From owner-multi6@ops.ietf.org Tue Jun 26 00:13:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06974 for ; Tue, 26 Jun 2001 00:13:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EjzT-000MOr-00 for multi6-data@psg.com; Mon, 25 Jun 2001 20:58:15 -0700 Received: from www.bit-net.com ([208.146.132.4] helo=mail.users.bit-net.com) by psg.com with smtp (Exim 3.16 #1) id 15EjzR-000MOk-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 20:58:13 -0700 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA31447; Mon, 25 Jun 2001 23:58:09 -0400 Date: Mon, 25 Jun 2001 23:58:09 -0400 (EDT) From: Jim Bound To: RJ Atkinson Cc: Jun-ichiro itojun Hagino , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <5.1.0.14.2.20010625152857.00a32760@10.30.15.2> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Ran, Excuse me but I was at the GSE meeting and the issue was no one felt it was technically feasible at the actual 8+8 meeting. Part of of the technical problem was we did not have the operators in the room as we do on this good wg mail list. The other problem was we had no notion of SCTP and did not get to the point Ohta San did by taking some of of the pain away. We also did not have the value of scoping quite down yet and that may help but I am not sure. But in the actual 8+8 meeting it was not political. Mike presented his case it was discussed and then an extended case from that was presented by ISI folks, close to where we are no on this list but it was not as clear as what we see now. If politics happened it happened after the 8+8 meeting and after the next IPng IETF meeting. Steve and Bob do a pretty good job of keeping the politics out of IPv6 for the most part. I don't recall you were at that meeting but my age may be playing tricks on me and if you were I apologize. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Mon, 25 Jun 2001, RJ Atkinson wrote: > At 13:56 25/06/01, Jun-ichiro itojun Hagino wrote: > > also, remember why GSE proposal was not integrated into IPv6 > > GSE was not integrated due to politics, pure and simple. Lets > please try to make technical decisions over here in multi6, rather > than repeat past political mistakes. > > > IPv6 is designed based on IPv4 experiences, and tries to benefit > > from the success of IPv4. if we add too many fundamental design > > changes into IPv6 (like 8+8 address rewrites on routers) > > we may not be able to success in IPv6, like IPv4 did. > > Itojun, > > 8+8 rewrites in a border router at 1/10 Gbps line speed aren't > worrying the major router vendors, AFAIK. Certainly it doesn't cause me > to lose sleep at night. However, we haven't yet decided whether we > want to take that approach or not. > > It IS sensible to try to sort out what problem(s) we are trying > to solve up front, without closing doors. Then we can try to sort things > out among various alternative approaches. Stopping the discussion > prematurely will guarantee failure, however. > > Ran > rja@inet.org > > From owner-multi6@ops.ietf.org Tue Jun 26 02:25:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20722 for ; Tue, 26 Jun 2001 02:25:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EmID-0000ZY-00 for multi6-data@psg.com; Mon, 25 Jun 2001 23:25:45 -0700 Received: from mg-206253200-2.ricochet.net ([206.253.200.2] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15EmIB-0000ZR-00 for multi6@ops.ietf.org; Mon, 25 Jun 2001 23:25:44 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 15EkHP-0000ya-00; Mon, 25 Jun 2001 21:16:47 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "marcelo" Cc: , , , Subject: Re: Survey on proposed IPv6 multi-homing mechanisms References: Message-Id: Date: Mon, 25 Jun 2001 21:16:47 -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit i hope you plan to produce this as an internet draft randy From owner-multi6@ops.ietf.org Tue Jun 26 04:29:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25172 for ; Tue, 26 Jun 2001 04:29:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EnsN-0003r9-00 for multi6-data@psg.com; Tue, 26 Jun 2001 01:07:11 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15EnsM-0003r3-00; Tue, 26 Jun 2001 01:07:11 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id DAA17963; Tue, 26 Jun 2001 03:07:19 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Tue, 26 Jun 2001 03:07:19 -0500 (CDT) From: "Jon (Taz) Mischo" To: Jim Bound cc: Brian E Carpenter , Randy Bush , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk It was Paul's idea, so initially, I'd say it would be appropriate for him to. I had some ideas I kind of tossed into the ring that I'd be happy to work on, but I must defer to Paul, as it's his brainchild :) -Taz On Mon, 25 Jun 2001, Jim Bound wrote: > could you or Paul take a stab at taking GxSE and extracting the reqs its > solves and we an put those in our reqs definition with other reqs. > > I do think it wise we have reqs and then solutions. > > > /jim > "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) > > > On Mon, 25 Jun 2001, Jon (Taz) Mischo wrote: > > > On Mon, 25 Jun 2001, Brian E Carpenter wrote: > > > > > Randy, I suggested some very precise requirements text to take account of the > > > fact that there is a lot of running and shipped code in existing products that > > > is simply not going to get rewritten that quickly. Like it or not, multi6 > > > has to coexist with vanilla IPv6, and that generates its own set of > > > requirements. > > > > Brian, if we can make something like GxSE work with vanilla v6, however, > > that should satisfy everyone. Instead of clobbering the discussion, I > > think we should expand it. There must be a happy medium. > > > > -Taz > > > > -- > > "Be liberal in what you accept, > > and conservative in what you send.." > > --Jon Postel (1943-1998) RFC 1122, October 1989 > > > > > > -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Tue Jun 26 09:05:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01691 for ; Tue, 26 Jun 2001 09:05:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Erif-000BBY-00 for multi6-data@psg.com; Tue, 26 Jun 2001 05:13:25 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.16 #1) id 15Erif-000BBS-00 for multi6@ops.ietf.org; Tue, 26 Jun 2001 05:13:25 -0700 Received: (qmail 13364 invoked by uid 100); 26 Jun 2001 12:13:17 -0000 Date: Tue, 26 Jun 2001 08:13:17 -0400 From: Joe Abley To: multi6@ops.ietf.org Subject: requirements draft revision Message-ID: <20010626081317.D27658@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, I've been sitting on this for a few days now, so I think it's time to throw it out for discussion. Note that I haven't given Ben time to check this over, so if there are gross errors they are mine and Vijay's, and you shouldn't blame him. I'm not happy with the requirements on transport-layer stability and survivability, but I wasn't able to find clear consensus in the mail archives on the issue. Perhaps we can put that issue to bed in -02. I have split out the description of v4 multi-homing to a separate document, as I think that makes things clearer. The v4 document is somewhat green, and could do with some attention (it might be useful to re-order the points as a compliance document against the reqs draft, for example, so it is more clear where it is deficient and where it exceeds the requirements). Anyway, flame on. http://www.automagic.org/~jabley/draft-ietf-multi6-multihoming-requirements-01.txt http://www.automagic.org/~jabley/draft-ietf-multi6-v4-multihoming-00.txt Joe From owner-multi6@ops.ietf.org Tue Jun 26 10:16:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09851 for ; Tue, 26 Jun 2001 10:16:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EtKX-000EVL-00 for multi6-data@psg.com; Tue, 26 Jun 2001 06:56:37 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([194.237.142.116]) by psg.com with esmtp (Exim 3.16 #1) id 15EtKV-000EVF-00 for multi6@ops.ietf.org; Tue, 26 Jun 2001 06:56:36 -0700 Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5QDuON24807; Tue, 26 Jun 2001 15:56:24 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id PAA18934; Tue, 26 Jun 2001 15:56:21 +0200 Message-ID: <3B389436.8245D388@era.ericsson.se> Date: Tue, 26 Jun 2001 15:55:02 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: marcelo CC: multi6@ops.ietf.org, alberto@it.uc3m.es, azcorra@it.uc3m.es, dlarra@it.uc3m.es, "mobile-ip@sunroof.eng.sun.com" Subject: Re: Survey on proposed IPv6 multi-homing mechanisms References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Marcelo, [cross-posting to mobile-ip list] marcelo wrote: > > Hi, > > We have been working on a survey of proposals related to IPv6 multi-homing. > We think that this could be a good input for a discussion about > which of these ideas can be valuable, and need to be further developed. > We have included all the mechanisms that we have found. If there are other > mechanisms, please let us know. We have also includes some advantages and > concerns about the mechanisms, but we think that discusion will really > disclose much more points. [...] > 5. Mobility mechanisms > > Another proposal presented in [DUPNOT] is based in the use of IP > mobility mechanisms. The main idea is to use the care-of-address > assignation mechanism to switch between delegated addresses in case of > failure. Suppose that there is an established communication between > > Survey on multi-homing mecanisms 7 > > hostA belonging to the multi-homed site and hostB, somewhere in the > Internet, as shown in figure 4. > > ___________________________________________ > | Internet | > | hostB | > |___________________________________________| > | | > | | > +----+ +----+ > |ISPA| |ISPB| > |BRA | |BRB | > +----+ +----+ > | | > link1 | | link2 > __|____________________________|___ > | RA RB | > | | | | > | ------------------------------- | > | | | > | hostA | > | PrefA:Prefsite:hostA | > | PrefB:Prefsite:hostA | > | | > |___________________________________| > > Figure 4: Mobility mechanisms > > The established connection is being routed through ISPA and > PrefA:Prefsite:hostA is used. If ISPA fails, the described steps are > followed in order to preserve communication: > - HostA packets contain the home address destination option with > PrefA:Prefsite:hostA and PrefB:Prefsite:hostA as source address, so > that for every device on the path source address is > PrefB:Prefsite:hostA and only hostB replaces this source address by > PrefA:Prefsite:hostA. > - HostA sends a binding update containing PrefB:Prefsite:hostA as a > care-of address. Note that that authentication header is needed in > this packet. > - HostB sends a binding acknowledgement. This packet and all next > packets are sent with PrefA:Prefsite:hostA as final destination > (included in a routing header) and PrefB:Prefsite:hostA as next > destination (included as destination address). Consequently, all > packets are sent towards HostA using ISPB, and address "translation" > is done when packets reach HostA. > > Mechanism Evaluation: > > Advantages: > > - The mechanism provides complete fault tolerance. > - It uses existing protocols. > - It allows ISP selection for load sharing. > > Survey on multi-homing mecanisms 8 > > Concerns > > - Needs Mobile IP implementation on destination host. So, modifications > in external hosts are needed to achieve internal multi-homing. > - Mobile IP security mechanisms impose the use of authentication header, > raising complexity. > > Currently, Mobile IP WG has to come up with a solution to establish security associations between the MN (host A) and the CN (host B). SA establishment using public key infrastructure is assumed to not be available everywhere and with all CNs. The (unofficially?) proposed draft-perkins-bake-00.txt suggests a (weak but strong enough for the purpose) mechanism that involves a home agent during the key exchange. The validity of the MN's binding of the home address is verified by the CN by sending packets via the home network. The home agent address belongs to the same prefix as the MN's home address, i.e. PrefA:Prefsite::. If no SA is set up prior to the failure of ISPA, the key exchange will fail since the CN can't send packets through the home agent any more. /Mattias From owner-multi6@ops.ietf.org Tue Jun 26 11:46:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23006 for ; Tue, 26 Jun 2001 11:46:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EuTd-000H30-00 for multi6-data@psg.com; Tue, 26 Jun 2001 08:10:05 -0700 Received: from melimelo.enst-bretagne.fr ([192.108.115.36]) by psg.com with esmtp (Exim 3.16 #1) id 15EuTc-000H2E-00 for multi6@ops.ietf.org; Tue, 26 Jun 2001 08:10:04 -0700 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5QF8fi35823; Tue, 26 Jun 2001 17:08:42 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA20117; Tue, 26 Jun 2001 17:08:41 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5QF8aO88923; Tue, 26 Jun 2001 17:08:36 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106261508.f5QF8aO88923@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mattias Pettersson cc: marcelo , multi6@ops.ietf.org, alberto@it.uc3m.es, azcorra@it.uc3m.es, dlarra@it.uc3m.es, "mobile-ip@sunroof.eng.sun.com" Subject: Re: Survey on proposed IPv6 multi-homing mechanisms In-reply-to: Your message of Tue, 26 Jun 2001 15:55:02 +0200. <3B389436.8245D388@era.ericsson.se> Date: Tue, 26 Jun 2001 17:08:36 +0200 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: [cross-posting to mobile-ip list] => please keep further messages in the multi6 list. > Concerns > > - Needs Mobile IP implementation on destination host. So, modifications > in external hosts are needed to achieve internal multi-homing. > - Mobile IP security mechanisms impose the use of authentication header, > raising complexity. Currently, Mobile IP WG has to come up with a solution to establish security associations between the MN (host A) and the CN (host B). SA establishment using public key infrastructure is assumed to not be available everywhere and with all CNs. => the mobility mechanism for IPv6 multi-homing was proposed before the security details were specified in the IPv6 mobility drafts... So don't expect that it works with any suggestion of this year (:-). More seriously, the idea was that if the mechanism is applied to critical connections then these connections are already protected by some mechanisms, i.e. the key material is already available or very easy to setup. The (unofficially?) proposed draft-perkins-bake-00.txt suggests a (weak but strong enough for the purpose) mechanism that involves a home agent during the key exchange. The validity of the MN's binding of the home address is verified by the CN by sending packets via the home network. The home agent address belongs to the same prefix as the MN's home address, i.e. PrefA:Prefsite::. If no SA is set up prior to the failure of ISPA, the key exchange will fail since the CN can't send packets through the home agent any more. => a SA set up prior to the failure of ISPA is the very easy case but can be common. Issues with the lack of home agent are different: - the CN should not flush the binding (i.e. a bit/sub-option/... is needed, its meaning should be "keep this binding as long as possible") - there is no support for mobile to mobile, in the multi-home environment this is translated by no support for failure on both the node and its CN ISPs or one has to assume that this condition is detectable. A common case is the failure of a high level ISP: if both nodes are connected to it they will see a failure at the same time, to understand this situation is hard but not impossible... I like this mechanism (of course :-) but we wait for the IPv6 mobility RFC before work again on it. BTW this is very easy to implement (movement detection is a dream). Regards Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Tue Jun 26 12:21:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24640 for ; Tue, 26 Jun 2001 12:21:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EvBO-000Ian-00 for multi6-data@psg.com; Tue, 26 Jun 2001 08:55:18 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15EvBN-000Iah-00 for multi6@ops.ietf.org; Tue, 26 Jun 2001 08:55:17 -0700 Received: from tnpfrancis ([10.10.1.239]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 26 Jun 2001 08:55:16 -0700 Message-ID: <000a01c0fe58$64969060$ef010a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Erik Nordmark" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Tue, 26 Jun 2001 08:55:16 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 26 Jun 2001 15:55:16.0758 (UTC) FILETIME=[64C4F360:01C0FE58] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Agree with all your points. yes, this moves complexity out of routing and into the application. Also, the multi-party application scenario I gave (A inside a site, talks to B outside a site, B learns A's GR addresses from the socket interface, then conveys them to C) is the easy case. A harder case is A inside the site, talks to B inside the site, then B wants to convey A's GR addresses to C. B won't know A's GR addresses because they are in the same site, so when A tells C about B's SK address (the only address B knows), C would have to deduce A's GR addresses from A's SK address combined with B's GR address prefixes learned from the socket. This in turn places constraints on A's and B's GR prefixes...i.e., they must be the same. Yuck. PF ----- Original Message ----- From: "Erik Nordmark" To: "Paul Francis" Cc: "Erik Nordmark" ; Sent: Monday, June 25, 2001 1:32 AM Subject: Re: An idea: GxSE > I think you are mis-understanding the model a little here (cause I wasn't > clear about this aspect in the original message). Applications should > operate in terms of passing the entire list of addresses around. SK > addresses should not be thought of as some magic token that can be used by > applications to learn GR addresses. Applications should know the GR > addresses from the start. How does an application learn its own GR addresses? > 1. A DNS lookup on the FQDN will return you the GR addresses (if you are > outside the target's site), suggesting that at least for the initial > contact, the application should be aware of the FQDN not the addresses. For the peer this is fine. But what about itself? > When host A talks to host B, host B learns the list of addresses by making > one of the above calls. Ideally host A never "identifies" itself to host B > in the application, host B simply does the first call while the socket is > still up, learns the whole list, and uses the whole list whenever it > identifies A, either internally or when talking to a third application at > host C. If for some reason it is necessary for host A to send its identity > to host B in the application layer, host A should preferably use its FQDN, > but could also use its SK address. I see how that can be made to work. The point is that I think this is a significant change in the way applications deal with their own addresses. Today they can just use getsockname(int sock,...) and pass this to peers. Thus whatever the new architecture needs to be for applications (handling addresses) the ramifications of this is best understood by folks with apps clue. I don't know how many of those we have on this list. BTW: Working out how IKE would work in the GxSE architecture would be a good test. (Even though IKE isn't a multi-party application it passes IP addresses around.) > An alternative approach would be to have the host attach a syntactically > correct address-list extension, but with empty place-holders for the GR > prefix list (instead of the "address-list trigger" extension I suggested > before). There would be a learning mechanism, whereby address-list > extensions would have a field indicating the number of GR prefixes, and this > field would be set on incoming packets. So if the host doesn't know the > number of prefixes, it would use a default, say 4. If it chooses too small > of a number, then it would learn that in a subsequent return packet. Of > course now the partner host would not have the complete list, but this would > not be a disaster. (Alternatively the sending host could always add one > more GR prefix placeholder than it thinks it needs, to catch the case where > a new prefix has recently been added.) I had the same idea. At least it works better than changing the length of the packets in the border routers. > Of course one could take this one step further, and simply have the > destination host return the source host's list of GR prefixes in the return > packet, so that the source host knows it too (on a connection by connection > basis---this would not be something the source host could generalize about > once the connection was closed). This could be an option selectable by the > application...(ah, the complexity creeps in!!!!) In a sense your moving the complexity of the routing system to handle scalable multihoming to the transport and applications layers. Erik From owner-multi6@ops.ietf.org Tue Jun 26 12:27:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24960 for ; Tue, 26 Jun 2001 12:27:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EvUx-000JIo-00 for multi6-data@psg.com; Tue, 26 Jun 2001 09:15:31 -0700 Received: from openbsd-0.lcs.mit.edu ([18.26.4.157] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.16 #1) id 15EvUw-000JIh-00 for multi6@ops.ietf.org; Tue, 26 Jun 2001 09:15:30 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 8AE1A7BC; Wed, 27 Jun 2001 01:14:42 +0900 (JST) To: Joe Abley Cc: multi6@ops.ietf.org In-reply-to: jabley-ietf's message of Tue, 26 Jun 2001 08:13:17 -0400. <20010626081317.D27658@buddha.home.automagic.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: requirements draft revision From: Jun-ichiro itojun Hagino Date: Wed, 27 Jun 2001 01:14:42 +0900 Message-Id: <20010626161442.8AE1A7BC@starfruit.itojun.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk thanks for the new document. > http://www.automagic.org/~jabley/draft-ietf-multi6-v4-multihoming-00.txt the document does not currently describe how the IPv4 multihoming is achieved. without describing it precisely, we cannot really go into discussions in section 4 and 5 (Features/Limitations of IPv4 Multihoming), as the features/limitations can change depending on how you set it up. i guess a section has to be added between 3 and 4, which describes the current practice (like "buy two circuit from two ISPs, get PI address space or PA from one of ISP, establish BGP with both, announce the address space to both). itojun From owner-multi6@ops.ietf.org Tue Jun 26 12:39:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24642 for ; Tue, 26 Jun 2001 12:21:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EvGU-000IlH-00 for multi6-data@psg.com; Tue, 26 Jun 2001 09:00:34 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15EvGU-000IlB-00 for multi6@ops.ietf.org; Tue, 26 Jun 2001 09:00:34 -0700 Received: from tnpfrancis ([10.10.1.239]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 26 Jun 2001 09:00:33 -0700 Message-ID: <001001c0fe59$215c3790$ef010a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Iljitsch van Beijnum" , "Paul Francis" Cc: References: Subject: Re: An idea: GxSE Date: Tue, 26 Jun 2001 09:00:32 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 26 Jun 2001 16:00:33.0454 (UTC) FILETIME=[2188ECE0:01C0FE59] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Renumbering is a pain, but running BGP or NAT is too. I'm not convinced > people are as desperate to avoid renumbering as you say. And this is in IPv4. > In IPv6 it somewhat unlikely that workstations that do not run any services > will be configured manually, and both prefix advertising and DHCP can handle > renumbering without too much of a hassle. > You may be right. PF From owner-multi6@ops.ietf.org Tue Jun 26 13:33:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28806 for ; Tue, 26 Jun 2001 13:33:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EwPK-000LK8-00 for multi6-data@psg.com; Tue, 26 Jun 2001 10:13:46 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 15EwPI-000LK0-00 for multi6@ops.ietf.org; Tue, 26 Jun 2001 10:13:45 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f5QHDbH02851; Tue, 26 Jun 2001 19:13:37 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 26 Jun 2001 19:13:34 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Joe Abley cc: multi6@ops.ietf.org Subject: Re: requirements draft revision In-Reply-To: <20010626081317.D27658@buddha.home.automagic.org> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 26 Jun 2001, Joe Abley wrote: > Anyway, flame on. Since you ask... > http://www.automagic.org/~jabley/draft-ietf-multi6-multihoming-requirements-01.txt "For purposes of redundancy and load sharing, the multihomed customer blocks, which are almost always a longer prefix from the provider aggregate, are announced, along with the larger aggregate by the provider." This reads like customer blocks always fall within a provider aggregate, which is not the case for PI address space. I think the users of a multihoming solution will have a few requirements of their own: 1. Multihoming should work even if the host on the other side of the connection uses a current (June 2001) IPv6 implementation. 2. If the solution requires cooperation of the transit providers, it should only require the cooperation between the customer and each of the transit networks individually and not directly between the transit networks. If these objectives aren't met it is likely that users will opt for traditional IPv4-like multihoming. > http://www.automagic.org/~jabley/draft-ietf-multi6-v4-multihoming-00.txt "A multi-homed enterprise may influence routing decisions beyond its immediate transit providers by advertising a strategic mixture of carefully-aimed long prefixes and covering shorter-prefix routes." This is one of the ways to accomplish inbound load balancing. Another widely used mechanism is path prepending. And some transit networks allow their customers to set communities for their routes that influence many things in the transit network which can also have broader effects (like prepending the path at certain exchange points). Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Jun 26 13:56:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01005 for ; Tue, 26 Jun 2001 13:56:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EwmO-000MAy-00 for multi6-data@psg.com; Tue, 26 Jun 2001 10:37:36 -0700 Received: from black-3.dsl.speakeasy.net ([216.231.56.189] helo=shell-beach.layer8.net) by psg.com with smtp (Exim 3.16 #1) id 15EwmN-000MAj-00 for multi6@ops.ietf.org; Tue, 26 Jun 2001 10:37:35 -0700 Received: (qmail 87268 invoked by uid 1000); 26 Jun 2001 17:32:58 -0000 Date: Tue, 26 Jun 2001 10:32:58 -0700 From: Ben Black To: "Jon \(Taz\) Mischo" Cc: Sean Doran , multi6@ops.ietf.org Subject: Re: An idea: GxSE Message-ID: <20010626103258.B86668@layer8.net> References: <20010620215009.1458388D@sean.ebone.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pvezYHf7grwyp3Bc" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from taz@tazlore.com on Wed, Jun 20, 2001 at 05:27:18PM -0500 Sender: owner-multi6@ops.ietf.org Precedence: bulk --pvezYHf7grwyp3Bc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 20, 2001 at 05:27:18PM -0500, Jon (Taz) Mischo wrote: > Border routers are often very heavily loaded. Announcing valid GR/SK > pairings via BGP or the like and then propagating them into an IGP > (OSPF/IS-IS) would allow you to make translations further into the > network, without renumbering. Basically, you could make the network > renumber itself. If this is done properly, you could keep the > intelligence at the edge, completely avoid renumbering, AND get better > routing/multihoming performance overall. This COULD be a win-win > situation, I just think we have to look at it from all angles and proceed > very carefully. >=20 The problem I ran into when thinking up something very similar to GxSE was that _only_ the border routers know the actual prefix at the egress point (barring end to end virtual circuits of some sort). =20 My solution was to distribute "valid" prefixes in the IGP and have them communicated to end hosts using an RIP-like mechanism to simply=20 broadcast the set of prefixes hosts on a given segment might be translated into (does that make sense?). Hosts would then inform remote ends of sessions (TCP, UDP, what have you), of the prefixes from which they might communicate. =20 Given the hop by hop nature of IP, I suspect it will be rather difficult to have the translations occur anywhere but at the border. Ben --pvezYHf7grwyp3Bc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: gzt0OZT1Q0guEMZ+ALMek1c+ZVvpm0VH iQA/AwUBOzjHSGM46bcYfOYxEQJftwCfUnqoQS5+cYU9B3bYeUOv3jwUGSAAoJJl siYTsqpXpjy+zMt/amahZP/R =YIZ1 -----END PGP SIGNATURE----- --pvezYHf7grwyp3Bc-- From owner-multi6@ops.ietf.org Tue Jun 26 13:56:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01018 for ; Tue, 26 Jun 2001 13:56:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Ex5E-000N0B-00 for multi6-data@psg.com; Tue, 26 Jun 2001 10:57:04 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.16 #1) id 15Ex5C-000N00-00 for multi6@ops.ietf.org; Tue, 26 Jun 2001 10:57:03 -0700 Received: (qmail 15930 invoked by uid 100); 26 Jun 2001 17:56:56 -0000 Date: Tue, 26 Jun 2001 13:56:56 -0400 From: Joe Abley To: Jun-ichiro itojun Hagino Cc: multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010626135656.R27658@buddha.home.automagic.org> References: <20010626081317.D27658@buddha.home.automagic.org> <20010626161442.8AE1A7BC@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010626161442.8AE1A7BC@starfruit.itojun.org>; from itojun@iijlab.net on Wed, Jun 27, 2001 at 01:14:42AM +0900 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, Jun 27, 2001 at 01:14:42AM +0900, Jun-ichiro itojun Hagino wrote: > thanks for the new document. > > > http://www.automagic.org/~jabley/draft-ietf-multi6-v4-multihoming-00.txt > > the document does not currently describe how the IPv4 multihoming > is achieved. without describing it precisely, we cannot really > go into discussions in section 4 and 5 (Features/Limitations of > IPv4 Multihoming), as the features/limitations can change > depending on how you set it up. > > i guess a section has to be added between 3 and 4, which describes > the current practice (like "buy two circuit from two ISPs, get > PI address space or PA from one of ISP, establish BGP with both, > announce the address space to both). I agree, that would certainly be helpful. If you feel like contributing some words, I'd be happy to paste them in. Joe From owner-multi6@ops.ietf.org Tue Jun 26 14:22:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01852 for ; Tue, 26 Jun 2001 14:22:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15ExTg-000O3e-00 for multi6-data@psg.com; Tue, 26 Jun 2001 11:22:20 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15ExTf-000O3V-00 for multi6@ops.ietf.org; Tue, 26 Jun 2001 11:22:19 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id NAA18675; Tue, 26 Jun 2001 13:22:20 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Tue, 26 Jun 2001 13:22:20 -0500 (CDT) From: "Jon (Taz) Mischo" To: Ben Black cc: Sean Doran , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <20010626103258.B86668@layer8.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 26 Jun 2001, Ben Black wrote: > My solution was to distribute "valid" prefixes in the IGP and have them > communicated to end hosts using an RIP-like mechanism to simply > broadcast the set of prefixes hosts on a given segment might be > translated into (does that make sense?). Hosts would then inform > remote ends of sessions (TCP, UDP, what have you), of the prefixes > from which they might communicate. This is similar to the idea I had expressed. > Given the hop by hop nature of IP, I suspect it will be rather difficult > to have the translations occur anywhere but at the border. Not at all. As I explained in a previous post, having the valid GR/SK pairs announced in BGP or the like and propagating them through the internal network via an IGP or a proptocols specifically designed for this purpose would let you translate in the distribution layer or even access layer (although in most cases the distribution layer routers would be the ones beefy enough to handle it of the two). This moves the intelligence pretty close to the edge. If you use my idea of using SK addresses that are globally unique as the actual endpoints of the connection, your hosts can be dumb as well. Therefore, it is possible to do GxSE with multiple remappings where only routers are aware of the remappings, thus making it backwards compatible with vanilla v6, except between your border router and the router in your network that is remapping. For connections not remapped, it has no effect. In fact, I think this is very important to note. It is possible to do this where remappings are done invisibly to the opposite end if there's not a GxSE router in the path between your GxSE remapper and the opposite endpoint of the connection. While you get a far less effective scenario, you still get SOME of the benefits, while allowing for vanilla v6. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Tue Jun 26 14:27:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02037 for ; Tue, 26 Jun 2001 14:27:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15ExE8-000NQg-00 for multi6-data@psg.com; Tue, 26 Jun 2001 11:06:16 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.16 #1) id 15ExE6-000NPm-00 for multi6@ops.ietf.org; Tue, 26 Jun 2001 11:06:15 -0700 Received: (qmail 14203 invoked by uid 100); 26 Jun 2001 18:06:08 -0000 Date: Tue, 26 Jun 2001 14:06:08 -0400 From: Joe Abley To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010626140607.S27658@buddha.home.automagic.org> References: <20010626081317.D27658@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from iljitsch@muada.com on Tue, Jun 26, 2001 at 07:13:34PM +0200 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, Jun 26, 2001 at 07:13:34PM +0200, Iljitsch van Beijnum wrote: > On Tue, 26 Jun 2001, Joe Abley wrote: > > > Anyway, flame on. > > Since you ask... Hooray! :) > > http://www.automagic.org/~jabley/draft-ietf-multi6-multihoming-requirements-01.txt > > "For purposes of redundancy and load sharing, the multihomed customer blocks, > which are almost always a longer prefix from the provider aggregate, are > announced, along with the larger aggregate by the provider." > > This reads like customer blocks always fall within a provider aggregate, > which is not the case for PI address space. That's very true. I think these bits need to be removed from the requirements documented, and described more accurately in the v4 draft, as itojun suggested. > I think the users of a multihoming solution will have a few requirements of > their own: > > 1. Multihoming should work even if the host on the other side of the > connection uses a current (June 2001) IPv6 implementation. Is this required in addition to 2.2.2 and 2.2.3? > 2. If the solution requires cooperation of the transit providers, it should > only require the cooperation between the customer and each of the transit > networks individually and not directly between the transit networks. How about this: A multihoming strategy may require coopreration between an enterprise and its transit providers, but must not require cooperation directly between the transit providers. > If these objectives aren't met it is likely that users will opt for > traditional IPv4-like multihoming. I agree. > > http://www.automagic.org/~jabley/draft-ietf-multi6-v4-multihoming-00.txt > > "A multi-homed enterprise may influence routing decisions beyond its > immediate transit providers by advertising a strategic mixture of > carefully-aimed long prefixes and covering shorter-prefix routes." > > This is one of the ways to accomplish inbound load balancing. Another widely > used mechanism is path prepending. And some transit networks allow their > customers to set communities for their routes that influence many things in > the transit network which can also have broader effects (like prepending the > path at certain exchange points). Very true, and worth mentioning. I will add words. Thanks! Joe From owner-multi6@ops.ietf.org Tue Jun 26 18:37:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01548 for ; Tue, 26 Jun 2001 18:37:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F0hW-0005LD-00 for multi6-data@psg.com; Tue, 26 Jun 2001 14:48:50 -0700 Received: from penguin-ext.wise.edt.ericsson.se ([194.237.142.110]) by psg.com with esmtp (Exim 3.16 #1) id 15F0hV-0005Jq-00 for multi6@ops.ietf.org; Tue, 26 Jun 2001 14:48:49 -0700 Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f5QLmfO06958; Tue, 26 Jun 2001 23:48:41 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id XAA00348; Tue, 26 Jun 2001 23:48:39 +0200 Message-ID: <3B3902E7.DA0B11D0@era.ericsson.se> Date: Tue, 26 Jun 2001 23:47:19 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: marcelo , multi6@ops.ietf.org, alberto@it.uc3m.es, azcorra@it.uc3m.es, dlarra@it.uc3m.es Subject: Re: Survey on proposed IPv6 multi-homing mechanisms References: <200106261508.f5QF8aO88923@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > In your previous mail you wrote: > > [cross-posting to mobile-ip list] > > => please keep further messages in the multi6 list. Ok. > > > Concerns > > > > - Needs Mobile IP implementation on destination host. So, modifications > > in external hosts are needed to achieve internal multi-homing. > > - Mobile IP security mechanisms impose the use of authentication header, > > raising complexity. > > Currently, Mobile IP WG has to come up with a solution to establish > security associations between the MN (host A) and the CN (host B). SA > establishment using public key infrastructure is assumed to not be > available everywhere and with all CNs. > > => the mobility mechanism for IPv6 multi-homing was proposed before > the security details were specified in the IPv6 mobility drafts... > So don't expect that it works with any suggestion of this year (:-). I know, just wanted to point out a realization problem. > More seriously, the idea was that if the mechanism is applied to > critical connections then these connections are already protected > by some mechanisms, i.e. the key material is already available or > very easy to setup. Sounds highly visionary to me. Maybe it can be so. > > The (unofficially?) proposed draft-perkins-bake-00.txt suggests a (weak > but strong enough for the purpose) mechanism that involves a home agent > during the key exchange. The validity of the MN's binding of the home > address is verified by the CN by sending packets via the home network. > The home agent address belongs to the same prefix as the MN's home > address, i.e. PrefA:Prefsite::. > > If no SA is set up prior to the failure of ISPA, the key exchange will > fail since the CN can't send packets through the home agent any more. > > => a SA set up prior to the failure of ISPA is the very easy case but > can be common. Issues with the lack of home agent are different: > - the CN should not flush the binding (i.e. a bit/sub-option/... > is needed, its meaning should be "keep this binding as long as possible") > - there is no support for mobile to mobile, in the multi-home environment > this is translated by no support for failure on both the node and > its CN ISPs or one has to assume that this condition is detectable. > A common case is the failure of a high level ISP: if both nodes > are connected to it they will see a failure at the same time, > to understand this situation is hard but not impossible... - Global PKI...? > I like this mechanism (of course :-) but we wait for the IPv6 mobility RFC > before work again on it. BTW this is very easy to implement (movement > detection is a dream). I agree that mobility has powerful mechanisms to overcome "small" problems such as multihoming... ;) Still some work has to be done because this won't work out of the box. /Mattias From owner-multi6@ops.ietf.org Tue Jun 26 19:11:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07708 for ; Tue, 26 Jun 2001 19:11:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F1bf-0007c3-00 for multi6-data@psg.com; Tue, 26 Jun 2001 15:46:51 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.16 #1) id 15F1be-0007bl-00 for multi6@ops.ietf.org; Tue, 26 Jun 2001 15:46:50 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id 8B6DD823; Wed, 27 Jun 2001 00:46:25 +0200 (CEST) To: ben@layer8.net, taz@tazlore.com Subject: Re: An idea: GxSE Cc: multi6@ops.ietf.org, smd@ebone.net Message-Id: <20010626224625.8B6DD823@sean.ebone.net> Date: Wed, 27 Jun 2001 00:46:25 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Jon (Taz) Mischo writes: | This is similar to the idea I had expressed. Let me see if I understand where you're headed. 1. split v6 address into two components: "SK" - unique and end-to-end "GR" - shared and local 2. The unique and end-to-end component corresponds to "who", as in "who is it that originated this packet" (satisfying Vixie) or as in "who is at the receiving end of this packet" (satisfying demulti- plexing) 3. The other component corresponds to "where", as in "where in the (local) topology can I find a hop much closer to my desired destination". IOW, "where" is a forwarding instruction for LOCAL routers that help them get towards the unique "who". 4. The forwarding instruction may cause _routers_ to do any number of things: discard packet (with or without signalling an error) forward a packet out a particular interface swap "labels" - forward out a particular interface but with a new forwarding instruction 5. Should _hosts_ which are not also routers EVER look at GR? Why? What should the host expect of a non-unique locally-scoped address component? 6. Should _routers_ ever touch the SK ("who") component? By "touch" I mean (a) mutate or (b) examine. The simple case for (b) is when the host examines SK to determine if the packet is addressed to the router itself. 5&6 go to the heart of the end-to-end against NAT argument, and I would be curious to see if any kind of consensus can be formed among the people with very strong (and opposite) views who are here on this list. I would also be interested in the input of host and router vendors who have some experience in implementing a variety of protocols. Sean. From owner-multi6@ops.ietf.org Wed Jun 27 00:20:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15232 for ; Wed, 27 Jun 2001 00:20:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F6bO-000FcU-00 for multi6-data@psg.com; Tue, 26 Jun 2001 21:06:54 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.16 #1) id 15F6bN-000FcN-00 for multi6@ops.ietf.org; Tue, 26 Jun 2001 21:06:53 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 26 Jun 2001 21:06:47 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 6FA6D66302924D14B5A708D8F3ED288C for plus 1 more; Tue, 26 Jun 2001 21:06:47 -0700 Reply-To: From: "Tony Hain" To: "Joe Abley" , Subject: RE: requirements draft revision Date: Tue, 26 Jun 2001 21:04:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010626081317.D27658@buddha.home.automagic.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: 9549E732-119140B8-B83AB427-F85AB826 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In multi6-multihoming-requirements requirement - 3.1.3 Performance - is simply bogus. The example given is managing traffic flows to avoid a specific remote congestion point. As it is not possible for any organization to reliably affect the routing policies of another organization (even the first hop), this is basically an unrealistic expectation. Taken to the limit, the requirement presented means every site has ultimate real-time control of routing policy for every service provider as well as all the remote sites they have active flows with. Even if each service provider wanted to cede control, the mismatch of policy constrains between the collections of end sites will assure this requirement can't be met because it has to be true for each of them. Since I assume you have some specific implementation in mind it might help if there were an example provided. Without that this requirement simply needs to be removed. Tony -----Original Message----- From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On Behalf Of Joe Abley Sent: Tuesday, June 26, 2001 5:13 AM To: multi6@ops.ietf.org Subject: requirements draft revision Hi, I've been sitting on this for a few days now, so I think it's time to throw it out for discussion. Note that I haven't given Ben time to check this over, so if there are gross errors they are mine and Vijay's, and you shouldn't blame him. I'm not happy with the requirements on transport-layer stability and survivability, but I wasn't able to find clear consensus in the mail archives on the issue. Perhaps we can put that issue to bed in -02. I have split out the description of v4 multi-homing to a separate document, as I think that makes things clearer. The v4 document is somewhat green, and could do with some attention (it might be useful to re-order the points as a compliance document against the reqs draft, for example, so it is more clear where it is deficient and where it exceeds the requirements). Anyway, flame on. http://www.automagic.org/~jabley/draft-ietf-multi6-multihoming-requirements- 01.txt http://www.automagic.org/~jabley/draft-ietf-multi6-v4-multihoming-00.txt Joe From owner-multi6@ops.ietf.org Wed Jun 27 01:05:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05060 for ; Wed, 27 Jun 2001 01:05:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F7H5-000Ghz-00 for multi6-data@psg.com; Tue, 26 Jun 2001 21:49:59 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15F7H4-000Ghs-00 for multi6@ops.ietf.org; Tue, 26 Jun 2001 21:49:58 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id XAA19405; Tue, 26 Jun 2001 23:50:06 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Tue, 26 Jun 2001 23:50:06 -0500 (CDT) From: "Jon (Taz) Mischo" To: Sean Doran cc: ben@layer8.net, multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <20010626224625.8B6DD823@sean.ebone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 27 Jun 2001, Sean Doran wrote: > Jon (Taz) Mischo writes: > > | This is similar to the idea I had expressed. > > Let me see if I understand where you're headed. > > 1. split v6 address into two components: > "SK" - unique and end-to-end > "GR" - shared and local Correct. > 2. The unique and end-to-end component corresponds to "who", as in > "who is it that originated this packet" (satisfying Vixie) or as > in "who is at the receiving end of this packet" (satisfying demulti- > plexing) Indeed. > 3. The other component corresponds to "where", as in "where in the > (local) topology can I find a hop much closer to my desired destination". > IOW, "where" is a forwarding instruction for LOCAL routers that help > them get towards the unique "who". Slight clarification. Local isn't the right word here. The SK portion would be local i.e. behind the remapping. GR would be used in front of the GR remapping. GR is used to tell the rest of the world how to get to the SK address via announcements. There may be more than one valid GR/SK pair announced. To the non-GxSE site, these look like multiple addresses for the same host, to the GxSE site, they look like multiple paths to the same host. As such, it is similar to landmark routing in that it tells any router along the way how to get closer to the SK address. Except for where rewriting occurs, however, this is fairly fixed (standard routing behavior). This is only variable when inside an administrative domain that maintains GR/SK pair mappings and has the authority to remap said address. In that case, the GR can be re-written to control the behavior between the host and the rewriting router, but only within the same domain. In other words, you can't redirect someone else's traffic. If you announce a set of viable GR/SK pairs to the world, someone else can't announce different GR's for your SK's globally. They could, however, remap within their own administrative domain, allowing them to control your path via rules instead of via metrics, for instance. > 4. The forwarding instruction may cause _routers_ to do any number of things: > discard packet (with or without signalling an error) > forward a packet out a particular interface > swap "labels" - forward out a particular interface but with a > new forwarding instruction Yes and no. You're treading on thin ice there. You're almost discussing MPLS. This is, however, different than MPLS. There is no label stacking, and thus you are limited in your remapping, unless you distribute your mappings within your own AD. You cannot announce your mappings unless you have authority over the SK. > 5. Should _hosts_ which are not also routers EVER look at GR? Why? > What should the host expect of a non-unique locally-scoped address > component? The GR would be unimportant to the host. However, this can be done in a manner to hide the GR mappings from the host. A non-unique locally scoped address should not be affected, as we are interested in unique addresses only. > 6. Should _routers_ ever touch the SK ("who") component? > By "touch" I mean (a) mutate or (b) examine. > The simple case for (b) is when the host examines SK to determine if > the packet is addressed to the router itself. (a) No, NEVER. If the SK is compromised, you have lost all the value of using GxSE. (b) Sometimes. If a router examines the GR and sees that it is autoritative for that GR, it would examine the SK to determine where to route the packet within the AD. > 5&6 go to the heart of the end-to-end against NAT argument, > and I would be curious to see if any kind of consensus can be > formed among the people with very strong (and opposite) views > who are here on this list. GxSE and NAT are mutually exclusive technologies. GxSE as I envision it takes the good things from NAT and mates them with end-to-end and routing concepts. NAT is much abused today. It was originally designed to deal with ISPs that didn't have the address space to allocate enough IP addresses, or had policies against doing so. It was a way for people to get around these problems. GxSE is the next logical step in evolution from NAT. It provides a way to deal with globally scoped unique addresses that allows for multihoming. IPv6 takes away some of the constraints that created NAT, though many people seem to think it is important for security. And it is, if you don't know how to write network policies. Of course, it is hardly "safe." Naturally, people will want to NAT GxSE. This is evil. It should be avoided. > I would also be interested in the input of host and router vendors > who have some experience in implementing a variety of protocols. > > Sean. -Jon -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jun 27 01:29:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17251 for ; Wed, 27 Jun 2001 01:29:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F7jM-000HMp-00 for multi6-data@psg.com; Tue, 26 Jun 2001 22:19:12 -0700 Received: from black-3.dsl.speakeasy.net ([216.231.56.189] helo=shell-beach.layer8.net) by psg.com with smtp (Exim 3.16 #1) id 15F7jM-000HMi-00 for multi6@ops.ietf.org; Tue, 26 Jun 2001 22:19:12 -0700 Received: (qmail 97631 invoked by uid 1000); 27 Jun 2001 05:14:43 -0000 Date: Tue, 26 Jun 2001 22:14:43 -0700 From: Ben Black To: "Jon \(Taz\) Mischo" Cc: Sean Doran , multi6@ops.ietf.org Subject: Re: An idea: GxSE Message-ID: <20010626221443.B96285@layer8.net> References: <20010626103258.B86668@layer8.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O5XBE6gyVG5Rl6Rj" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from taz@tazlore.com on Tue, Jun 26, 2001 at 01:22:20PM -0500 Sender: owner-multi6@ops.ietf.org Precedence: bulk --O5XBE6gyVG5Rl6Rj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 26, 2001 at 01:22:20PM -0500, Jon (Taz) Mischo wrote: > > Given the hop by hop nature of IP, I suspect it will be rather difficult > > to have the translations occur anywhere but at the border. >=20 > Not at all. As I explained in a previous post, having the valid GR/SK > pairs announced in BGP or the like and propagating them through the > internal network via an IGP or a proptocols specifically designed for this > purpose would let you translate in the distribution layer or even access > layer (although in most cases the distribution layer routers would be the > ones beefy enough to handle it of the two). >=20 This doesn't address the concern I noted above which is that the interior routers simply don't know the egress router, and hence the egress prefix (assuming you always map into space provided by a given upstream, which is how I would expect to avoid rapid table growth). This information _could_ be communicated to the interior routers, but it would require them to carry full reachability information, which seems a rather onerous requirement. Ben --O5XBE6gyVG5Rl6Rj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: 1oHekkZJtR+Zslf/0OI3PDN8m1UtiNlO iQA/AwUBOzlrwWM46bcYfOYxEQKZJACglUPyp4WHLQcYDJKM1xg9C4HVWSUAnRW1 QmgCqL3aBKZrj40dVG3eN4ej =gXkk -----END PGP SIGNATURE----- --O5XBE6gyVG5Rl6Rj-- From owner-multi6@ops.ietf.org Wed Jun 27 03:16:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA19605 for ; Wed, 27 Jun 2001 03:16:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F9Yx-000KNg-00 for multi6-data@psg.com; Wed, 27 Jun 2001 00:16:35 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15F9Yw-000KNZ-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 00:16:34 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id CAA19737; Wed, 27 Jun 2001 02:16:43 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 27 Jun 2001 02:16:42 -0500 (CDT) From: "Jon (Taz) Mischo" To: Ben Black cc: Sean Doran , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <20010626221443.B96285@layer8.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk I understand your point, but with careful construction this shouldn't be an issue. Assuming you use a link state protocol for the interior portion and you allow the border routers to notify the interior routers of the egress point, you could move the rewrite closer to the edge. In fact, if you let the initial rewrite occur at the egress router, and then move the rewrite backwards into the network, with the egress router indicating validity of all recently used routes back into the IGP/other protocol for this purpose, you would know where the packets are going. Basically, if there is a topology change, you just need to make sure your path is still valid. Another behavior to control this may be to stop rewriting at the edge if you detect a topology change that may affect your internal routing, and let the egress router rewrite and re-alert you. I had another point, but I forgot it...serves me right for stepping away to deal with something else. -Jon On Tue, 26 Jun 2001, Ben Black wrote: > On Tue, Jun 26, 2001 at 01:22:20PM -0500, Jon (Taz) Mischo wrote: > > > Given the hop by hop nature of IP, I suspect it will be rather difficult > > > to have the translations occur anywhere but at the border. > > > > Not at all. As I explained in a previous post, having the valid GR/SK > > pairs announced in BGP or the like and propagating them through the > > internal network via an IGP or a proptocols specifically designed for this > > purpose would let you translate in the distribution layer or even access > > layer (although in most cases the distribution layer routers would be the > > ones beefy enough to handle it of the two). > > > > This doesn't address the concern I noted above which is that the interior > routers simply don't know the egress router, and hence the egress prefix > (assuming you always map into space provided by a given upstream, which > is how I would expect to avoid rapid table growth). This information > _could_ be communicated to the interior routers, but it would require them > to carry full reachability information, which seems a rather onerous > requirement. > > > Ben > > -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jun 27 03:29:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27303 for ; Wed, 27 Jun 2001 03:29:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F9cl-000KUE-00 for multi6-data@psg.com; Wed, 27 Jun 2001 00:20:31 -0700 Received: from black-3.dsl.speakeasy.net ([216.231.56.189] helo=shell-beach.layer8.net) by psg.com with smtp (Exim 3.16 #1) id 15F9ck-000KU3-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 00:20:30 -0700 Received: (qmail 99371 invoked by uid 1000); 27 Jun 2001 07:16:03 -0000 Date: Wed, 27 Jun 2001 00:16:03 -0700 From: Ben Black To: "Jon \(Taz\) Mischo" Cc: Sean Doran , multi6@ops.ietf.org Subject: Re: An idea: GxSE Message-ID: <20010627001603.A99237@layer8.net> References: <20010626221443.B96285@layer8.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from taz@tazlore.com on Wed, Jun 27, 2001 at 02:16:42AM -0500 Sender: owner-multi6@ops.ietf.org Precedence: bulk --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 27, 2001 at 02:16:42AM -0500, Jon (Taz) Mischo wrote: > I understand your point, but with careful construction this shouldn't be > an issue. Assuming you use a link state protocol for the interior portion > and you allow the border routers to notify the interior routers of the > egress point, you could move the rewrite closer to the edge. In fact, if In order to do that, the interior routers carry full tables. Whether the information is distributed via BGP, an IGP (an unpleasant thought), or by some mechanism specific to this purpose, the issue remains. > you let the initial rewrite occur at the egress router, and then move the > rewrite backwards into the network, with the egress router indicating > validity of all recently used routes back into the IGP/other protocol for > this purpose, you would know where the packets are going. >=20 > Basically, if there is a topology change, you just need to make sure > your path is still valid. Another behavior to control this may be to stop > rewriting at the edge if you detect a topology change that may affect your > internal routing, and let the egress router rewrite and re-alert you. >=20 I shudder to consider the troubleshooting implications of this. Ben --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: KvXQKbw3H+VYDsE1+i218Bbec+nyMi3D iQA/AwUBOzmIMmM46bcYfOYxEQL1ygCeJNiFJZ5wSK/6KGEHZO7b0hUNQRgAmwdK iQ41ALsxZHeCg+l3QCF8V8vS =5ari -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- From owner-multi6@ops.ietf.org Wed Jun 27 07:03:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26659 for ; Wed, 27 Jun 2001 07:03:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FCjn-000PKU-00 for multi6-data@psg.com; Wed, 27 Jun 2001 03:39:59 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.16 #1) id 15FCjm-000PKO-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 03:39:58 -0700 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17173; Wed, 27 Jun 2001 04:39:55 -0600 (MDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id DAA06046; Wed, 27 Jun 2001 03:41:18 -0700 (PDT) Received: from buse (buse.France.Sun.COM [129.157.212.11]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5RAdrU173700; Wed, 27 Jun 2001 03:39:54 -0700 (PDT) Date: Wed, 27 Jun 2001 12:39:52 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: An idea: GxSE To: Paul Francis Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <000a01c0fe58$64969060$ef010a0a@tahoenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > Agree with all your points. yes, this moves complexity out of routing and > into the application. > > Also, the multi-party application scenario I gave (A inside a site, talks to > B outside a site, B learns A's GR addresses from the socket interface, then > conveys them to C) is the easy case. A harder case is A inside the site, > talks to B inside the site, then B wants to convey A's GR addresses to C. B > won't know A's GR addresses because they are in the same site, so when A > tells C about B's SK address (the only address B knows), C would have to > deduce A's GR addresses from A's SK address combined with B's GR address > prefixes learned from the socket. > > This in turn places constraints on A's and B's GR prefixes...i.e., they must > be the same. I wonder if it makes sense exploring the case when applications (as well as transports like SCTP) can easily find out the GR addresses of their own node, but those addresses are not used in the IP packets. You'll have issues like the applications discovering potentially stale information but conceptually I don't think that is much different than getting stale DNS information when looking up the peers addresses in the DNS. Erik From owner-multi6@ops.ietf.org Wed Jun 27 07:38:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18765 for ; Wed, 27 Jun 2001 07:38:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FDSe-0000cj-00 for multi6-data@psg.com; Wed, 27 Jun 2001 04:26:20 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.16 #1) id 15FDSd-0000cc-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 04:26:19 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f5RBQPH04296; Wed, 27 Jun 2001 13:26:25 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 27 Jun 2001 13:26:12 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Joe Abley cc: multi6@ops.ietf.org Subject: Re: requirements draft revision In-Reply-To: <20010626140607.S27658@buddha.home.automagic.org> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 26 Jun 2001, Joe Abley wrote: > > 1. Multihoming should work even if the host on the other side of the > > connection uses a current (June 2001) IPv6 implementation. > Is this required in addition to 2.2.2 and 2.2.3? Don't you mean 3.2.3? The current way of multihoming requires only the multihomed network and its transit providers to take any action. If the new way of multihoming requires action (upgrading software) by the other end, obviously this will be less effective because the number of sites that upgrade their software will always be less than 100%. So "old" multihoming would be superior to "new" multihoming so it is very likely that networks will continue to use the old way until this becomes less attractive for some reason, such as cost or default-free networks filtering their routes. Basically, I'm saying the new way of multihoming should be at least as attractive to most users as the current way. > > 2. If the solution requires cooperation of the transit providers, it should > > only require the cooperation between the customer and each of the transit > > networks individually and not directly between the transit networks. > How about this: > A multihoming strategy may require coopreration between an enterprise > and its transit providers, but must not require cooperation directly > between the transit providers. Excellent. From owner-multi6@ops.ietf.org Wed Jun 27 13:02:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24382 for ; Wed, 27 Jun 2001 13:02:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FH88-0007H9-00 for multi6-data@psg.com; Wed, 27 Jun 2001 08:21:24 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.16 #1) id 15FH87-0007Fo-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 08:21:23 -0700 Received: (qmail 32095 invoked by uid 100); 27 Jun 2001 15:21:17 -0000 Date: Wed, 27 Jun 2001 11:21:17 -0400 From: Joe Abley To: "Jon \(Taz\) Mischo" Cc: Ben Black , Sean Doran , multi6@ops.ietf.org Subject: Re: An idea: GxSE Message-ID: <20010627112116.C27658@buddha.home.automagic.org> References: <20010626221443.B96285@layer8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from taz@tazlore.com on Wed, Jun 27, 2001 at 02:16:42AM -0500 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, Jun 27, 2001 at 02:16:42AM -0500, Jon (Taz) Mischo wrote: > I understand your point, but with careful construction this shouldn't be > an issue. Assuming you use a link state protocol for the interior portion > and you allow the border routers to notify the interior routers of the > egress point, you could move the rewrite closer to the edge. In fact, if > you let the initial rewrite occur at the egress router, and then move the > rewrite backwards into the network, with the egress router indicating > validity of all recently used routes back into the IGP/other protocol for > this purpose, you would know where the packets are going. This may be a trivial point, but I know many "edge enterprises" (i.e. customers) who have extrordinary difficulty in running an IGP, and either wind up statically-routing everything within their network or use a fantastic mixture of RIP, EIGRP and OSPF corresponding to the various waves of contractors that have been brought in to fix things at different times. These people can currently multi-home just fine, since all the multi- homing smarts are constrained to one or two BGP-speaking border routers, which is a nice black box that "our BGP guy" can handle without impinging on the hoardes of other junk connected in the network. This is just a tentatively-raised red-tinged warning flag: requirements involving IGPs may prove onerous to end-users. Joe From owner-multi6@ops.ietf.org Wed Jun 27 13:04:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24457 for ; Wed, 27 Jun 2001 13:04:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FI5S-0009VK-00 for multi6-data@psg.com; Wed, 27 Jun 2001 09:22:42 -0700 Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by psg.com with esmtp (Exim 3.16 #1) id 15FI5R-0009TV-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 09:22:41 -0700 Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA11542; Wed, 27 Jun 2001 09:22:04 -0700 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA22360; Wed, 27 Jun 2001 09:22:10 -0700 Message-ID: <3B3A05C8.20A9B0F1@hursley.ibm.com> Date: Wed, 27 Jun 2001 11:11:52 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Joe Abley CC: multi6@ops.ietf.org Subject: Re: requirements draft revision References: <20010626081317.D27658@buddha.home.automagic.org> <3B39F2AC.4D8B565A@hursley.ibm.com> <20010627114101.F27658@buddha.home.automagic.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe Abley wrote: > > On Wed, Jun 27, 2001 at 09:50:20AM -0500, Brian E Carpenter wrote: > > My comments on the -01 draft (presumably you will post it officially?) > > It is coming. Yes, in fact it came, thanks. > > > You define the SHOULD/MUST/etc terminology but don't use it. I think this > > is important - some of the requirements should be SHOULDs and some of > > them must be MUSTs, but I don't think that is correct yet in the text. > > For example, imho 3.1.1 should be MUST, but it starts with a "should". > > I suggest a pass through the draft to clarify this everywhere. > > Yes, thanks for reminding me. I will attempt to do that shortly. > > > 3.1.1: > > > > > The multihoming architecture must accommodate (in the general case, > > > issues of shared-fate notwithstanding) the following failure modes: > > > > I don't find the parenthesis very clear. Suggestion: > > (in general, disregarding the survival of individual sessions > > as covered by section 3.1.6) > > That's not what I meant. An example of what I was trying to convey is > that to protect against local-loop failure, it is reasonable to order > two access circuits. However, if those two access circuits happen to > run through the same building access, over the same fibre, through > the same SONET mux, etc, etc, then in practice you may not be protecting > yourself from many of the likely reasons for failure. Those two circuits > have "shared fate". OK, so your phrase does need clarifying. > > > 3.1.6: > > > > > Multihoming solutions must provide re-homing transparency for > > > transport-layer protocols; > > > > I think we have to be more precise. Firstly it isn't the protocol that > > survives, it's the session. Secondly, does this include UDP? Suggestion: > > > > Multihoming solutions must provide re-homing transparency for > > transport-layer sessions, including protocols such as > > TCP and SCTP, and purely stateless protocols built on UDP. > > That certainly makes things clearer. > > > [actually what about applications built on raw IP??] > > If we put a re-homing transparency requirement in for those, aren't we > mandating that end-point IP addresses must survive through a re-homing? > Doesn't that bring us back to exactly where we are today? I think so. So it should be stated as a non-requirement. Brian From owner-multi6@ops.ietf.org Wed Jun 27 13:09:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24667 for ; Wed, 27 Jun 2001 13:09:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FGa0-00064b-00 for multi6-data@psg.com; Wed, 27 Jun 2001 07:46:08 -0700 Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by psg.com with esmtp (Exim 3.16 #1) id 15FGZz-00064L-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 07:46:07 -0700 Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id HAA30166; Wed, 27 Jun 2001 07:45:32 -0700 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA23508; Wed, 27 Jun 2001 07:45:35 -0700 Message-ID: <3B39EF3F.909D7CC@hursley.ibm.com> Date: Wed, 27 Jun 2001 09:35:43 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Joe Abley , multi6@ops.ietf.org Subject: Re: requirements draft revision References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On Tue, 26 Jun 2001, Joe Abley wrote: > > > > 1. Multihoming should work even if the host on the other side of the > > > connection uses a current (June 2001) IPv6 implementation. > > > Is this required in addition to 2.2.2 and 2.2.3? > > Don't you mean 3.2.3? I think he does. I think it is required (perhaps as an update to 3.2.3) to make it clear that an updated host can communicate with a non-updated host (without survivability). > > The current way of multihoming requires only the multihomed network and its > transit providers to take any action. > > If the new way of multihoming requires action (upgrading software) by the > other end, obviously this will be less effective because the number of sites > that upgrade their software will always be less than 100%. And people still use Windows 3.1. We can't make this a killer argument for host updates - that's exactly why I drafted 3.2.3. > > So "old" multihoming would be superior to "new" multihoming so it is very > likely that networks will continue to use the old way until this becomes less > attractive for some reason, such as cost or default-free networks filtering > their routes. Exactly. That's why we're here - to find a strategic solution. > > Basically, I'm saying the new way of multihoming should be at least as > attractive to most users as the current way. In the long term. Brian From owner-multi6@ops.ietf.org Wed Jun 27 13:11:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24754 for ; Wed, 27 Jun 2001 13:11:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FI3c-0009Ps-00 for multi6-data@psg.com; Wed, 27 Jun 2001 09:20:48 -0700 Received: from [63.108.254.91] (helo=gnat.inet.org) by psg.com with esmtp (Exim 3.16 #1) id 15FI3c-0009NG-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 09:20:48 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 399BE8266E; Wed, 27 Jun 2001 12:20:15 -0400 (EDT) Message-Id: <5.1.0.14.2.20010627121126.00a37d80@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Jun 2001 12:16:16 -0400 To: Joe Abley From: RJ Atkinson Subject: Re: requirements draft revision Cc: multi6@ops.ietf.org In-Reply-To: <20010627114101.F27658@buddha.home.automagic.org> References: <3B39F2AC.4D8B565A@hursley.ibm.com> <20010626081317.D27658@buddha.home.automagic.org> <3B39F2AC.4D8B565A@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 11:41 27/06/01, Joe Abley wrote: >> I think we have to be more precise. Firstly it isn't the protocol that >> survives, it's the session. Secondly, does this include UDP? Suggestion: >> >> Multihoming solutions must provide re-homing transparency for >> transport-layer sessions, including protocols such as >> TCP and SCTP, and purely stateless protocols built on UDP. > >That certainly makes things clearer. > >> [actually what about applications built on raw IP??] > >If we put a re-homing transparency requirement in for those, aren't we >mandating that end-point IP addresses must survive through a re-homing? >Doesn't that bring us back to exactly where we are today? Not necessarily. One possible approach for transport-layer protocols, one that seems reasonable to some folks, is that the Protocol Control Block for a given session would not contain an IP address, though it might contain some other identifier(s). Also note that while UDP is characterised as stateless, all implementations that I'm familiar with have normal Protocol Control Blocks even for UDP sessions -- so as implemented and deployed there is some non-zero UDP state already. For protocols built on raw IP, they could also use some other form of identifier in lieu of an IP address, if such an identifier were found and agreed upon. [Aside: it is in this respect that it would be nice if the folks in the IRTF NSRG could focus on producing drafts on the matter of alternate/additional namespaces. Right now there's some discussion, but few if any drafts over there, which seems like a bug.] Ran From owner-multi6@ops.ietf.org Wed Jun 27 13:12:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24814 for ; Wed, 27 Jun 2001 13:12:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FHYT-0008Eq-00 for multi6-data@psg.com; Wed, 27 Jun 2001 08:48:37 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15FHYT-0008Ek-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 08:48:37 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15FHYT-0006cu-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 08:48:37 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 15FD75-000PyH-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 04:04:03 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26276; Wed, 27 Jun 2001 07:03:21 -0400 (EDT) Message-Id: <200106271103.HAA26276@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-multi6-multihoming-requirements-01.txt Date: Wed, 27 Jun 2001 07:03:21 -0400 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Multihoming in IPv6 Working Group of the IETF. Title : Requirements for IP Multihoming Architectures Author(s) : B. Black, V. Gill, J. Abley Filename : draft-ietf-multi6-multihoming-requirements-01.txt Pages : 10 Date : 26-Jun-01 Multihoming is an essential component of service for enterprises [3] which are part of the Internet. Existing IPv4 multi-homing practices, described in a companion draft [1], provides a set of capabilities that must be accommodated by the adopted multi-homing architecture in IPv6, and a set of limitations that must be overcome, relating in particular to scalability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-requirements-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-multi6-multihoming-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-multi6-multihoming-requirements-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010626132221.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-multi6-multihoming-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-multi6-multihoming-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010626132221.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Wed Jun 27 13:13:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24908 for ; Wed, 27 Jun 2001 13:13:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FHRA-0007vi-00 for multi6-data@psg.com; Wed, 27 Jun 2001 08:41:04 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.16 #1) id 15FHR9-0007vc-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 08:41:04 -0700 Received: (qmail 15589 invoked by uid 100); 27 Jun 2001 15:41:02 -0000 Date: Wed, 27 Jun 2001 11:41:02 -0400 From: Joe Abley To: Brian E Carpenter Cc: multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010627114101.F27658@buddha.home.automagic.org> References: <20010626081317.D27658@buddha.home.automagic.org> <3B39F2AC.4D8B565A@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B39F2AC.4D8B565A@hursley.ibm.com>; from brian@hursley.ibm.com on Wed, Jun 27, 2001 at 09:50:20AM -0500 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, Jun 27, 2001 at 09:50:20AM -0500, Brian E Carpenter wrote: > My comments on the -01 draft (presumably you will post it officially?) It is coming. > You define the SHOULD/MUST/etc terminology but don't use it. I think this > is important - some of the requirements should be SHOULDs and some of > them must be MUSTs, but I don't think that is correct yet in the text. > For example, imho 3.1.1 should be MUST, but it starts with a "should". > I suggest a pass through the draft to clarify this everywhere. Yes, thanks for reminding me. I will attempt to do that shortly. > 3.1.1: > > > The multihoming architecture must accommodate (in the general case, > > issues of shared-fate notwithstanding) the following failure modes: > > I don't find the parenthesis very clear. Suggestion: > (in general, disregarding the survival of individual sessions > as covered by section 3.1.6) That's not what I meant. An example of what I was trying to convey is that to protect against local-loop failure, it is reasonable to order two access circuits. However, if those two access circuits happen to run through the same building access, over the same fibre, through the same SONET mux, etc, etc, then in practice you may not be protecting yourself from many of the likely reasons for failure. Those two circuits have "shared fate". > 3.1.6: > > > Multihoming solutions must provide re-homing transparency for > > transport-layer protocols; > > I think we have to be more precise. Firstly it isn't the protocol that > survives, it's the session. Secondly, does this include UDP? Suggestion: > > Multihoming solutions must provide re-homing transparency for > transport-layer sessions, including protocols such as > TCP and SCTP, and purely stateless protocols built on UDP. That certainly makes things clearer. > [actually what about applications built on raw IP??] If we put a re-homing transparency requirement in for those, aren't we mandating that end-point IP addresses must survive through a re-homing? Doesn't that bring us back to exactly where we are today? Thanks for the feedback! Joe From owner-multi6@ops.ietf.org Wed Jun 27 13:15:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24965 for ; Wed, 27 Jun 2001 13:15:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FHLp-0007m1-00 for multi6-data@psg.com; Wed, 27 Jun 2001 08:35:33 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.16 #1) id 15FHLo-0007lv-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 08:35:33 -0700 Received: (qmail 22018 invoked by uid 100); 27 Jun 2001 15:35:31 -0000 Date: Wed, 27 Jun 2001 11:35:31 -0400 From: Joe Abley To: Tony Hain Cc: multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010627113530.E27658@buddha.home.automagic.org> References: <20010626081317.D27658@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alh-ietf@tndh.net on Tue, Jun 26, 2001 at 09:04:15PM -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, Jun 26, 2001 at 09:04:15PM -0700, Tony Hain wrote: > In multi6-multihoming-requirements requirement - 3.1.3 Performance - is > simply bogus. The example given is managing traffic flows to avoid a > specific remote congestion point. As it is not possible for any organization > to reliably affect the routing policies of another organization (even the > first hop), this is basically an unrealistic expectation. In the current v4 architecture, it is overwhelmingly usual for an operator to assign a higher local preference to prefixes received from a customer than from a peer. If I am a customer of T1, I can be very confident that the path from T1 to me will follow the prefixes I advertise rather than a route through a peer, for advertisements of the same mask length. This absolutely happens today, and people absolutely multi-home today in order to accomplish this. > Taken to the > limit, the requirement presented means every site has ultimate real-time > control of routing policy for every service provider as well as all the > remote sites they have active flows with. Even if each service provider > wanted to cede control, the mismatch of policy constrains between the > collections of end sites will assure this requirement can't be met because > it has to be true for each of them. > > Since I assume you have some specific implementation in mind it might help > if there were an example provided. Without that this requirement simply > needs to be removed. This requirement comes from the observed fact that this happens today, and works very reliably. Suppose for a second a large, popular on-line auction company obtained transit through one particular provider, and that provider had a problem of peering congestion to some other large promising regional ISP that was taking months to sort out. An immediate solution for the auction company was to purchase transit from the promising regional ISP, which eliminates the congestion point that had been causing them such pain. [note that the congestion condition hypothetically alluded to above would surely no longer be an issue, if we consider the fabricated example to be real in some way] Joe From owner-multi6@ops.ietf.org Wed Jun 27 13:16:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25013 for ; Wed, 27 Jun 2001 13:16:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FHEB-0007TL-00 for multi6-data@psg.com; Wed, 27 Jun 2001 08:27:39 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.16 #1) id 15FHEB-0007TB-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 08:27:39 -0700 Received: (qmail 31675 invoked by uid 100); 27 Jun 2001 15:27:38 -0000 Date: Wed, 27 Jun 2001 11:27:38 -0400 From: Joe Abley To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010627112737.D27658@buddha.home.automagic.org> References: <20010626140607.S27658@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from iljitsch@muada.com on Wed, Jun 27, 2001 at 01:26:12PM +0200 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, Jun 27, 2001 at 01:26:12PM +0200, Iljitsch van Beijnum wrote: > On Tue, 26 Jun 2001, Joe Abley wrote: > > > > 1. Multihoming should work even if the host on the other side of the > > > connection uses a current (June 2001) IPv6 implementation. > > > Is this required in addition to 2.2.2 and 2.2.3? > > Don't you mean 3.2.3? Yeah :) > The current way of multihoming requires only the multihomed network and its > transit providers to take any action. > > If the new way of multihoming requires action (upgrading software) by the > other end, obviously this will be less effective because the number of sites > that upgrade their software will always be less than 100%. Ah, I see -- I misunderstood what you meant by "other side of the connection" -- you're talking about a remote endpoint of a transport- layer session, right? Perhaps we can generalise the paragraph I suggested (below) to include this requirement, which seems very sensible to me. > Basically, I'm saying the new way of multihoming should be at least as > attractive to most users as the current way. Absolutely. That is the crux of the matter. > > > 2. If the solution requires cooperation of the transit providers, it should > > > only require the cooperation between the customer and each of the transit > > > networks individually and not directly between the transit networks. > > > How about this: > > > A multihoming strategy may require coopreration between an enterprise > > and its transit providers, but must not require cooperation directly > > between the transit providers. > > Excellent. Joe From owner-multi6@ops.ietf.org Wed Jun 27 13:17:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25051 for ; Wed, 27 Jun 2001 13:17:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FGoF-0006b9-00 for multi6-data@psg.com; Wed, 27 Jun 2001 08:00:51 -0700 Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by psg.com with esmtp (Exim 3.16 #1) id 15FGoE-0006Zy-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 08:00:50 -0700 Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA46030; Wed, 27 Jun 2001 08:00:14 -0700 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA19942; Wed, 27 Jun 2001 08:00:19 -0700 Message-ID: <3B39F2AC.4D8B565A@hursley.ibm.com> Date: Wed, 27 Jun 2001 09:50:20 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Joe Abley CC: multi6@ops.ietf.org Subject: Re: requirements draft revision References: <20010626081317.D27658@buddha.home.automagic.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit My comments on the -01 draft (presumably you will post it officially?) You define the SHOULD/MUST/etc terminology but don't use it. I think this is important - some of the requirements should be SHOULDs and some of them must be MUSTs, but I don't think that is correct yet in the text. For example, imho 3.1.1 should be MUST, but it starts with a "should". I suggest a pass through the draft to clarify this everywhere. 3.1.1: > The multihoming architecture must accommodate (in the general case, > issues of shared-fate notwithstanding) the following failure modes: I don't find the parenthesis very clear. Suggestion: (in general, disregarding the survival of individual sessions as covered by section 3.1.6) 3.1.6: > Multihoming solutions must provide re-homing transparency for > transport-layer protocols; I think we have to be more precise. Firstly it isn't the protocol that survives, it's the session. Secondly, does this include UDP? Suggestion: Multihoming solutions must provide re-homing transparency for transport-layer sessions, including protocols such as TCP and SCTP, and purely stateless protocols built on UDP. [actually what about applications built on raw IP??] Brian Joe Abley wrote: > > Hi, > > I've been sitting on this for a few days now, so I think it's time to > throw it out for discussion. Note that I haven't given Ben time to check > this over, so if there are gross errors they are mine and Vijay's, and > you shouldn't blame him. > > I'm not happy with the requirements on transport-layer stability and > survivability, but I wasn't able to find clear consensus in the mail > archives on the issue. Perhaps we can put that issue to bed in -02. > > I have split out the description of v4 multi-homing to a separate > document, as I think that makes things clearer. The v4 document is > somewhat green, and could do with some attention (it might be useful to > re-order the points as a compliance document against the reqs draft, > for example, so it is more clear where it is deficient and where it > exceeds the requirements). > > Anyway, flame on. > > http://www.automagic.org/~jabley/draft-ietf-multi6-multihoming-requirements-01.txt > http://www.automagic.org/~jabley/draft-ietf-multi6-v4-multihoming-00.txt > > Joe -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. From owner-multi6@ops.ietf.org Wed Jun 27 13:17:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25109 for ; Wed, 27 Jun 2001 13:17:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FGIF-0005Zd-00 for multi6-data@psg.com; Wed, 27 Jun 2001 07:27:47 -0700 Received: from [63.108.254.91] (helo=gnat.inet.org) by psg.com with esmtp (Exim 3.16 #1) id 15FGIE-0005Y2-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 07:27:46 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 39DC78266E for ; Wed, 27 Jun 2001 10:27:03 -0400 (EDT) Message-Id: <5.1.0.14.2.20010627101816.01f5dd90@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Jun 2001 10:23:05 -0400 To: multi6@ops.ietf.org From: RJ Atkinson Subject: Re: An idea: GxSE In-Reply-To: References: <20010626221443.B96285@layer8.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 03:16 27/06/01, Jon (Taz) Mischo wrote: >I understand your point, but with careful construction this shouldn't be >an issue. Assuming you use a link state protocol for the interior portion >and you allow the border routers to notify the interior routers of the >egress point, you could move the rewrite closer to the edge. If there are multiple egress points, then either one is carrying full routes in the link-state IGP that you postulate xor the modification happens at the site border router only. The site border router must be listening to EBGP anyway if it is multihomed, so it already would have the data needed for reasonable path selection. The latter is a lot simpler. IMHO, simpler is better. >In fact, if >you let the initial rewrite occur at the egress router, and then move the >rewrite backwards into the network, with the egress router indicating >validity of all recently used routes back into the IGP/other protocol for >this purpose, you would know where the packets are going. Operational folks probably won't generally tolerate putting all that extra stuff into the IGP, because it makes a complex system a great deal more complex. This is particularly true in multi-homed enterprises, most of which just run a plain old IGP (e.g. RIPv2, OSPF) and are unlikely to deploy protocols common in ISPs (e.g. I-BGP, IS-IS). An alternative would be a new kind of ICMP message from the border router back to the originating host. This could be authenticated (e.g. using AH) in situations where such authentication was a concern. >Basically, if there is a topology change, you just need to make sure >your path is still valid. Another behavior to control this may be to stop >rewriting at the edge if you detect a topology change that may affect your >internal routing, and let the egress router rewrite and re-alert you. The latter is simpler and consequently more palatable, IMHO. Ran From owner-multi6@ops.ietf.org Wed Jun 27 13:18:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25151 for ; Wed, 27 Jun 2001 13:18:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FGzv-0006y8-00 for multi6-data@psg.com; Wed, 27 Jun 2001 08:12:55 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.16 #1) id 15FGzv-0006y2-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 08:12:55 -0700 Received: from tnpfrancis ([10.10.1.241]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 27 Jun 2001 08:12:53 -0700 Message-ID: <000d01c0ff1b$a30138a0$f1010a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Paul Francis" Cc: "Erik Nordmark" , References: Subject: Re: An idea: GxSE Date: Wed, 27 Jun 2001 08:12:52 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 27 Jun 2001 15:12:53.0936 (UTC) FILETIME=[A38ADB00:01C0FF1B] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > I wonder if it makes sense exploring the case when applications > (as well as transports like SCTP) can easily find out the GR addresses > of their own node, but those addresses are not used in the IP packets. > I was wondering about this myself. Like an anycast ping to the nearest site border router... PF From owner-multi6@ops.ietf.org Wed Jun 27 13:29:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00681 for ; Wed, 27 Jun 2001 13:29:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FIiy-000AzL-00 for multi6-data@psg.com; Wed, 27 Jun 2001 10:03:32 -0700 Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by psg.com with esmtp (Exim 3.16 #1) id 15FIix-000AwZ-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 10:03:31 -0700 Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id KAA29456; Wed, 27 Jun 2001 10:02:48 -0700 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id KAA23566; Wed, 27 Jun 2001 10:02:48 -0700 Message-ID: <3B3A0F46.2155CE52@hursley.ibm.com> Date: Wed, 27 Jun 2001 11:52:22 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Jon (Taz) Mischo" CC: Sean Doran , ben@layer8.net, multi6@ops.ietf.org Subject: Re: An idea: GxSE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Jon (Taz) Mischo" wrote: ... > GxSE and NAT are mutually exclusive technologies. I once characterised 8+8 as "architected NAT", and both GSE and GxSE fall into that category - essentially by clearly separating the mutable (locator) part from the immutable (identifier) part. I suspect that this separation will turn out to be a required property of the multi6 solution, and there are a number of ways to achieve it. Brian From owner-multi6@ops.ietf.org Wed Jun 27 14:10:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28005 for ; Wed, 27 Jun 2001 14:10:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FJVm-000CeB-00 for multi6-data@psg.com; Wed, 27 Jun 2001 10:53:58 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.30 #1) id 15FJVl-000Ce5-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 10:53:57 -0700 Received: (qmail 17018 invoked by uid 100); 27 Jun 2001 17:53:56 -0000 Date: Wed, 27 Jun 2001 13:53:56 -0400 From: Joe Abley To: Tony Hain Cc: multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010627135355.M27658@buddha.home.automagic.org> References: <20010627113530.E27658@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alh-ietf@tndh.net on Wed, Jun 27, 2001 at 10:36:22AM -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, Jun 27, 2001 at 10:36:22AM -0700, Tony Hain wrote: > You effectively proved my point. It is not possible to reliably affect the > routing policy of an external organization (else the need to purchase access > to the opposite side of the congestion point would not be necessary). My point was that it is trivial to affect the routing policy of an external organisation by buying transit from them. > Also > you appear to be targeting a relatively simple topology of managing the > immediate providers, but the wording implies that any solution is required > to work over an arbitrarily complex one. The wording is: 3.1.3 Performance By multihoming, an enterprise should be able to protect itself from performance difficulties between transit providers. For example, suppose enterprise E obtains transit from transit providers T1 and T2, and there is long-term congestion between T1 and T2. The multihoming architecture should allow E to ensure that in normal operation none of its traffic is carried over the congested interconnection T1-T2. A multi-homed enterprise must also be able to distribute inbound traffic particular multiple transit providers according to the particular network within their enterprise which is sourcing or sinking the traffic. If I made the first paragraph "between its transit providers" rather than "between transit providers" would thae make it clearer? > [snip] > > /--ISP 1--><--ISP 2--><--ISP 3--\ > Remote Site< >Popular site > \--ISP 4--> Congestion<--ISP 5--/ The requirement here is that "popular site" should be able to multi-home between ISP4 and ISP5 in order to avoid congestion between ISP4 and ISP5. > The policy of 'remote site' is to always prefer its low-cost path to ISP 4. > The wording requires that the multi-homing solution allow 'Popular site' to > override the routing to ensure a bypass of the congestion. That can't happen > because it violates the policy of the other end. Acquiring service from ISP > 4 or coercing 4 to connect to 2 or 3 are about the only options here. See above. > There are current topologies where existing tools have an effect, but they > have a limited scope. Tat needs to be recognized and they need to be added > as examples, or the requirement is unobtainable and needs to be removed. I still don't see what is unobtainable about the requirement, given that it describes motivations for multi-homing that are achievable today with v4/CIDR-abuse. Joe From owner-multi6@ops.ietf.org Wed Jun 27 14:11:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28789 for ; Wed, 27 Jun 2001 14:11:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FJHL-000Bwx-00 for multi6-data@psg.com; Wed, 27 Jun 2001 10:39:03 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.16 #1) id 15FJHH-000Bwc-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 10:39:00 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 27 Jun 2001 10:38:31 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 486E72A615F840F592C40927382EC8AE for plus 1 more; Wed, 27 Jun 2001 10:38:31 -0700 Reply-To: From: "Tony Hain" To: "Joe Abley" Cc: Subject: RE: requirements draft revision Date: Wed, 27 Jun 2001 10:36:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010627113530.E27658@buddha.home.automagic.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: 027F9B6A-A2864646-92A89F9F-1EDBF301 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit You effectively proved my point. It is not possible to reliably affect the routing policy of an external organization (else the need to purchase access to the opposite side of the congestion point would not be necessary). Also you appear to be targeting a relatively simple topology of managing the immediate providers, but the wording implies that any solution is required to work over an arbitrarily complex one. If your intent was simply to say that 'an enterprise must be able to acquire service from any provider', that is very different. The open question in both cases is how many entities need to know the topological details and preference, and how much can one override the operational biases of the interconnection mesh. The implied assertion is that it is sufficient for a site to inform the global set of service providers what it wants and magic will happen. But if the routing policy of said 'popular on-line auction house' was contradictory to the outbound routing policy of an arbitrarily distant site where one of the customers happened to be located, it is not possible for 'popular on-line auction house' to do anything to directly affect the path of those packets. /--ISP 1--><--ISP 2--><--ISP 3--\ Remote Site< >Popular site \--ISP 4--> Congestion<--ISP 5--/ The policy of 'remote site' is to always prefer its low-cost path to ISP 4. The wording requires that the multi-homing solution allow 'Popular site' to override the routing to ensure a bypass of the congestion. That can't happen because it violates the policy of the other end. Acquiring service from ISP 4 or coercing 4 to connect to 2 or 3 are about the only options here. There are current topologies where existing tools have an effect, but they have a limited scope. Tat needs to be recognized and they need to be added as examples, or the requirement is unobtainable and needs to be removed. Tony -----Original Message----- From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On Behalf Of Joe Abley Sent: Wednesday, June 27, 2001 8:36 AM To: Tony Hain Cc: multi6@ops.ietf.org Subject: Re: requirements draft revision On Tue, Jun 26, 2001 at 09:04:15PM -0700, Tony Hain wrote: > In multi6-multihoming-requirements requirement - 3.1.3 Performance - is > simply bogus. The example given is managing traffic flows to avoid a > specific remote congestion point. As it is not possible for any organization > to reliably affect the routing policies of another organization (even the > first hop), this is basically an unrealistic expectation. In the current v4 architecture, it is overwhelmingly usual for an operator to assign a higher local preference to prefixes received from a customer than from a peer. If I am a customer of T1, I can be very confident that the path from T1 to me will follow the prefixes I advertise rather than a route through a peer, for advertisements of the same mask length. This absolutely happens today, and people absolutely multi-home today in order to accomplish this. > Taken to the > limit, the requirement presented means every site has ultimate real-time > control of routing policy for every service provider as well as all the > remote sites they have active flows with. Even if each service provider > wanted to cede control, the mismatch of policy constrains between the > collections of end sites will assure this requirement can't be met because > it has to be true for each of them. > > Since I assume you have some specific implementation in mind it might help > if there were an example provided. Without that this requirement simply > needs to be removed. This requirement comes from the observed fact that this happens today, and works very reliably. Suppose for a second a large, popular on-line auction company obtained transit through one particular provider, and that provider had a problem of peering congestion to some other large promising regional ISP that was taking months to sort out. An immediate solution for the auction company was to purchase transit from the promising regional ISP, which eliminates the congestion point that had been causing them such pain. [note that the congestion condition hypothetically alluded to above would surely no longer be an issue, if we consider the fabricated example to be real in some way] Joe From owner-multi6@ops.ietf.org Wed Jun 27 14:37:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11249 for ; Wed, 27 Jun 2001 14:37:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FKCa-000Dj3-00 for multi6-data@psg.com; Wed, 27 Jun 2001 11:38:12 -0700 Received: from mx1out.umbc.edu ([130.85.253.51]) by psg.com with esmtp (Exim 3.30 #1) id 15FKCZ-000Div-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 11:38:11 -0700 Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx1out.umbc.edu (8.11.3/8.11.3) with ESMTP id f5RIcAR19215; Wed, 27 Jun 2001 14:38:10 -0400 (EDT) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id OAA12883981; Wed, 27 Jun 2001 14:38:09 -0400 (EDT) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Wed, 27 Jun 2001 14:38:09 -0400 From: Vijay Gill X-X-Sender: To: Tony Hain cc: Joe Abley , Subject: RE: requirements draft revision In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 26 Jun 2001, Tony Hain wrote: > In multi6-multihoming-requirements requirement - 3.1.3 Performance - > is simply bogus. The example given is managing traffic flows to avoid > a specific remote congestion point. As it is not possible for any > organization to reliably affect the routing policies of another > organization (even the first hop), this is basically an unrealistic > expectation. Taken to the limit, the requirement presented means every > site has ultimate real-time Many organizations, including the networks I've worked on, have specific communities that can be used to color prefixes, such that the routing policy is changed for those prefixes. /vijay From owner-multi6@ops.ietf.org Wed Jun 27 14:57:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23221 for ; Wed, 27 Jun 2001 14:57:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FKI3-000DqN-00 for multi6-data@psg.com; Wed, 27 Jun 2001 11:43:51 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.30 #1) id 15FKI3-000DqH-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 11:43:51 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id NAA20604; Wed, 27 Jun 2001 13:44:00 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 27 Jun 2001 13:44:00 -0500 (CDT) From: "Jon (Taz) Mischo" To: RJ Atkinson cc: multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <5.1.0.14.2.20010627101816.01f5dd90@10.30.15.2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 27 Jun 2001, RJ Atkinson wrote: > If there are multiple egress points, then either one is > carrying full routes in the link-state IGP that you postulate > xor the modification happens at the site border router only. > The site border router must be listening to EBGP anyway if it > is multihomed, so it already would have the data needed for reasonable > path selection. I was talking about a design that specifically didn't require route redistribution. Except in NSPs and larger running IS-IS, you generally don't have that sort of route distribution. Your IGP will generally reliably get you to the same border router. It may send you to a different border router due to IBGP, but these behaviors are fairly static. As such, it's pretty easy to alert back towards the host that a rewrite needs to happen, and let the nearest capable router take care of it. > The latter is a lot simpler. IMHO, simpler is better. I agree that simplicity is often better. > >In fact, if > >you let the initial rewrite occur at the egress router, and then move the > >rewrite backwards into the network, with the egress router indicating > >validity of all recently used routes back into the IGP/other protocol for > >this purpose, you would know where the packets are going. > > Operational folks probably won't generally tolerate putting > all that extra stuff into the IGP, because it makes a complex system > a great deal more complex. This is particularly true in multi-homed > enterprises, most of which just run a plain old IGP (e.g. RIPv2, OSPF) > and are unlikely to deploy protocols common in ISPs (e.g. I-BGP, IS-IS). "All that extra stuff" is actually 1 thing if you use the ICMP message you talk about below. The one thing is the ability to signal that it has routing table stability or doesn't have routing table stability. Furthermore, you would only want to move rewriting into the network if you are running a link state protocol, as I said before. This means OSPF, IS-IS, or EIGRP (which is really a hybrid and non-standard, but it IS used in lieu of IS-IS sometimes). > An alternative would be a new kind of ICMP message from > the border router back to the originating host. This could be > authenticated (e.g. using AH) in situations where such authentication > was a concern. An ICMP message sent back towards the host with rewriting directions would, indeed, be a good way to move the rewrite further back in the network. > >Basically, if there is a topology change, you just need to make sure > >your path is still valid. Another behavior to control this may be to stop > >rewriting at the edge if you detect a topology change that may affect your > >internal routing, and let the egress router rewrite and re-alert you. > > The latter is simpler and consequently more palatable, IMHO. Agreed. But it means either an indication into the IGP that there is some sort of route instability, or another ICMP message towards the host indicating that rewriting should be done at the egress point again. Another point is that if there's some route flap going on, you may want a rewrite indication dampening period. Even if you are incorrectly rewriting near the edge, your border routers are still capable of rewriting, since they'll recognize the SK and decide that the GR is incorrect and rewrite it. If there's instability between core routers, this could creat an ICMP storm or delayed convergence in an IGP, so a dampening period might be wise. The main reason for moving the rewrite back is that you don't want to be putting all of the work on the border routers all of the time. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jun 27 15:20:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09754 for ; Wed, 27 Jun 2001 15:20:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FKdc-000Eh4-00 for multi6-data@psg.com; Wed, 27 Jun 2001 12:06:08 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.30 #1) id 15FKdb-000Egu-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 12:06:08 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 27 Jun 2001 12:05:52 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id C60F83258E4248EDB3173813ABC3B892 for plus 2 more; Wed, 27 Jun 2001 12:05:52 -0700 Reply-To: From: "Tony Hain" To: "Vijay Gill" Cc: "Joe Abley" , Subject: RE: requirements draft revision Date: Wed, 27 Jun 2001 12:03:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: A595FE28-5D224ECF-B93F7564-CB4DA640 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Vijay Gill wrote: > Many organizations, including the networks I've worked on, have > specific communities that can be used to color prefixes, such > that the routing policy is changed for those prefixes. This works within the scope of the community. As soon as it violates some higher-level policy of an arbitrary third-party though it will be ignored. My point was simply that multi6 requirements can't be setting us up to do more than current technology allows. The wording needs to be precise so that it requires continuing current practice without expanding the scope unrealistically. Tony From owner-multi6@ops.ietf.org Wed Jun 27 15:20:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09801 for ; Wed, 27 Jun 2001 15:20:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FKUX-000ELa-00 for multi6-data@psg.com; Wed, 27 Jun 2001 11:56:45 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.30 #1) id 15FKUW-000ELU-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 11:56:44 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 27 Jun 2001 11:56:39 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 5E89BC956F60480496C1B9ACFA75EF60 for plus 1 more; Wed, 27 Jun 2001 11:56:38 -0700 Reply-To: From: "Tony Hain" To: "Joe Abley" Cc: Subject: RE: requirements draft revision Date: Wed, 27 Jun 2001 11:54:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010627135355.M27658@buddha.home.automagic.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: D260E073-82A8460A-A75B87A2-B4457F80 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe Abley wrote: > My point was that it is trivial to affect the routing policy of > an external organisation by buying transit from them. Then why couldn't 'popular site' trivially affect the routing policy of 'one particular provider' to bypass the path? After all they bought transit from them. All that a site can hope to affect is the 'internal' routing policy of a service provider, and then only because that is the service being bought. > If I made the first paragraph "between its transit providers" > rather than "between transit providers" would thae make it > clearer? It would certainly limit the scope of the statement to what is achievable today. > The requirement here is that "popular site" should be able > to multi-home between ISP4 and ISP5 in order to avoid > congestion between ISP4 and ISP5. Basically what you are saying here is that 'any site should be able to acquire services from an arbitrary set of providers'. But the statement in the draft goes significantly further: "The multihoming architecture should allow E to ensure that in normal operation none of its traffic is carried over the congested interconnection T1-T2." This implies that any multi-homed E has realtime control of global routing policies of all other organizations. The best that E can hope for is that traffic from direct customers of T1 & T2 not be carried over the congested path. It may through selective announcements be able to affect some traffic beyond the direct customers of T1 & T2, but it can't do that reliably on a global scale. > I still don't see what is unobtainable about the requirement, > given that it describes motivations for multi-homing that are > achievable today with v4/CIDR-abuse. The words used are overly broad compared to actual practice. I don't have a problem with requiring that current practice be continued, but make sure the words are not setting us up to require something beyond reality. Tony From owner-multi6@ops.ietf.org Wed Jun 27 15:21:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09861 for ; Wed, 27 Jun 2001 15:21:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FKLk-000DwW-00 for multi6-data@psg.com; Wed, 27 Jun 2001 11:47:40 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.30 #1) id 15FKLj-000DwO-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 11:47:40 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id NAA20618; Wed, 27 Jun 2001 13:47:46 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 27 Jun 2001 13:47:46 -0500 (CDT) From: "Jon (Taz) Mischo" To: Joe Abley cc: Ben Black , Sean Doran , multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <20010627112116.C27658@buddha.home.automagic.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 27 Jun 2001, Joe Abley wrote: > This is just a tentatively-raised red-tinged warning flag: requirements > involving IGPs may prove onerous to end-users. Perhaps it will comfort you to know that the only time you actually NEED something in the IGP, or need to use new ICMP messages is when you actually ARE moving the rewrite into the network. If you don't have the expertise to run an IGP, you shouldn't be moving the rewrite to the edge, you should just let the border routers do it. Moving it towards the edge simply reduces the load of the border routers. Any enterprise that doesn't have capable network engineers probably doesn't have any edge routers capable of anything more than dropping every other packet, if you get my drift. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jun 27 15:26:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13938 for ; Wed, 27 Jun 2001 15:26:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FKax-000EcJ-00 for multi6-data@psg.com; Wed, 27 Jun 2001 12:03:23 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.30 #1) id 15FKaw-000EbN-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 12:03:22 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id C718D8266E; Wed, 27 Jun 2001 15:02:49 -0400 (EDT) Message-Id: <5.1.0.14.2.20010627145034.009f9820@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Jun 2001 14:58:51 -0400 To: "Jon (Taz) Mischo" From: RJ Atkinson Subject: Re: An idea: GxSE Cc: multi6@ops.ietf.org In-Reply-To: References: <5.1.0.14.2.20010627101816.01f5dd90@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 14:44 27/06/01, Jon (Taz) Mischo wrote: >I was talking about a design that specifically didn't require route >redistribution. Except in NSPs and larger running IS-IS, you generally >don't have that sort of route distribution. Your IGP will generally >reliably get you to the same border router. It may send you to a >different border router due to IBGP, but these behaviors are fairly >static. As such, it's pretty easy to alert back towards the host that a >rewrite needs to happen, and let the nearest capable router take care of >it. We need an approach that handles large end-user organisations (consider: GE, HP, NRL) where not all upstream trunks have interfaces in a single router. NRL's campus, which has ~3000 users at one site, used to have 3-4 separate routers with upstream connections (don't know what their topology is these days). It is precisely that sort of site that is more likely to be multi-homed, IMHO. >> Operational folks probably won't generally tolerate putting >> all that extra stuff into the IGP, because it makes a complex system >> a great deal more complex. This is particularly true in multi-homed >> enterprises, most of which just run a plain old IGP (e.g. RIPv2, OSPF) >> and are unlikely to deploy protocols common in ISPs (e.g. I-BGP, IS-IS). > >"All that extra stuff" is actually 1 thing if you use the ICMP message you >talk about below. The one thing is the ability to signal that it has >routing table stability or doesn't have routing table >stability. Furthermore, you would only want to move rewriting into the >network if you are running a link state protocol, as I said before. This >means OSPF, IS-IS, or EIGRP (which is really a hybrid and non-standard, >but it IS used in lieu of IS-IS sometimes). Right, so I'd much rather use that ICMP message, work with any IGP, not change any IGP, and not put any extra gorp in the IGP. A multihoming approach ought to work equally well if one is using RIPv2. Lots of sites can and do use RIPv2 as their IGP. RIPv2 is more common when there is a single border router with 1 or more uplinks to different service providers, IMHO. It is fine provided the scale of the site is reasonable and the site has been structured in a thoughtful manner. RIP is also much easier to configure than a typical link-state IGP. Note that my objection is to putting any additional goop into any of the IGPs (I don't consider IBGP to be an IGP). Perhaps I misunderstood your note ? >An ICMP message sent back towards the host with rewriting directions >would, indeed, be a good way to move the rewrite further back in the >network. Or just tell the host to change its own source address for that session and continue to let the site border router(s) rewrite the destination if appropriate... >Agreed. But it means either an indication into the IGP that there is some >sort of route instability, or another ICMP message towards the host >indicating that rewriting should be done at the egress point again. Or the egress point just does the rewrite and also throws a clue back to the origin host, without putting any gorp into the IGP. >The main reason for moving the rewrite back is that you don't want to be >putting all of the work on the border routers all of the time. I don't object to letting folks move the rewrite back or to letting the host participate in such decisions. I will note that I'm truly not worried about a router performing the rewrite over say 10 Gbps Ethernet uplink to an ISP at full line rate. Forwarding ASICs are your friend. Other folks mileage might vary of course... Ran From owner-multi6@ops.ietf.org Wed Jun 27 15:41:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17795 for ; Wed, 27 Jun 2001 15:41:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FKSz-000EHT-00 for multi6-data@psg.com; Wed, 27 Jun 2001 11:55:09 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.30 #1) id 15FKSy-000EHN-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 11:55:08 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id NAA20642; Wed, 27 Jun 2001 13:55:15 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 27 Jun 2001 13:55:15 -0500 (CDT) From: "Jon (Taz) Mischo" To: Brian E Carpenter cc: Sean Doran , ben@layer8.net, multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <3B3A0F46.2155CE52@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 27 Jun 2001, Brian E Carpenter wrote: > > GxSE and NAT are mutually exclusive technologies. > > I once characterised 8+8 as "architected NAT", and both GSE and GxSE > fall into that category - essentially by clearly separating the mutable > (locator) part from the immutable (identifier) part. I suspect that > this separation will turn out to be a required property of the multi6 > solution, and there are a number of ways to achieve it. Agreed, I was saying that just to prove how opinionated I am on the subject. If you read on, though, I THINK I wrote that GxSE basically takes lessons learned from NAT and applies them and multihoming practices to v6. This may, however, be what I forgot what I was writing the above. I'm really just trying to say that GxSE is being discussed as a way to avoid having to use true NAT (where the entire address is translated, as is the definiteion of NAT) by making a similar mechanism part of the addressing scheme natively. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jun 27 15:41:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17809 for ; Wed, 27 Jun 2001 15:41:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FL3P-000FzH-00 for multi6-data@psg.com; Wed, 27 Jun 2001 12:32:47 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.30 #1) id 15FL3O-000FzA-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 12:32:46 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id OAA20715; Wed, 27 Jun 2001 14:32:57 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 27 Jun 2001 14:32:57 -0500 (CDT) From: "Jon (Taz) Mischo" To: RJ Atkinson cc: multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <5.1.0.14.2.20010627145034.009f9820@10.30.15.2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 27 Jun 2001, RJ Atkinson wrote: > >static. As such, it's pretty easy to alert back towards the host that a > >rewrite needs to happen, and let the nearest capable router take care of > >it. > > We need an approach that handles large end-user organisations > (consider: GE, HP, NRL) where not all upstream trunks have interfaces > in a single router. NRL's campus, which has ~3000 users at one > site, used to have 3-4 separate routers with upstream connections > (don't know what their topology is these days). You need to re-read some of what I've said about how this rewriting is actually done. You could have 20,000 border routers. The behavior is still the same. A border router merely looks at the SK address of a packet when it is going into an egress queue, and makes sure the GR is appropriate. If it's not, it rewrites the GR. This may not happen on the queue, this may happen in an asic on the port...there are many ways to implement it. > It is precisely that sort of site that is more likely to be > multi-homed, IMHO. They are a type of multi-homed site. > Right, so I'd much rather use that ICMP message, work with any > IGP, not change any IGP, and not put any extra gorp in the IGP. As a former Network Engineer for a few large networks (including one of the largest ISPs in the history of the US), I can tell you I'd tolerate a new directive in an IGP better than a whole slew of ICMP messages to every host every time Joe Blow's route flaps. > A multihoming approach ought to work equally well if one is > using RIPv2. Lots of sites can and do use RIPv2 as their IGP. RIPv2 > is more common when there is a single border router with 1 or more > uplinks to different service providers, IMHO. It is fine provided > the scale of the site is reasonable and the site has been structured > in a thoughtful manner. RIP is also much easier to configure than > a typical link-state IGP. RIP is used in some cases, yes. It is good for very simple networks. GxSE works better with a link state protocol because it has faster convergence and notices something is wrong a lot faster. GxSE would work just fine with RIP, it just wouldn't be as efficient. That is just a basic of routing, however. > Note that my objection is to putting any additional goop > into any of the IGPs (I don't consider IBGP to be an IGP). Perhaps > I misunderstood your note ? I think you may not have seen why I was talking about link state IGPs. The additional goop actually would HELP, in that it would prevent packet storms. Most network engineers dislike packet storms. > >An ICMP message sent back towards the host with rewriting directions > >would, indeed, be a good way to move the rewrite further back in the > >network. > > Or just tell the host to change its own source address > for that session and continue to let the site border router(s) > rewrite the destination if appropriate... ummm? I don't think you understand GxSE. Source addresses get rewritten, not destination. The point is NOT to have to do what you just said. That's what we're trying to avoid. > >Agreed. But it means either an indication into the IGP that there is some > >sort of route instability, or another ICMP message towards the host > >indicating that rewriting should be done at the egress point again. > > Or the egress point just does the rewrite and also throws a clue > back to the origin host, without putting any gorp into the IGP. Origin host doesn't need a clue. My approach is for a stupid host. Doesn't need to know, unless it specifically asks because it is doing something like IPsec. > >The main reason for moving the rewrite back is that you don't want to be > >putting all of the work on the border routers all of the time. > > I don't object to letting folks move the rewrite back > or to letting the host participate in such decisions. > > I will note that I'm truly not worried about a router > performing the rewrite over say 10 Gbps Ethernet uplink to an ISP > at full line rate. Forwarding ASICs are your friend. Other folks > mileage might vary of course... Heh. The point is that ASIC changes mean hardware changes. That's even more slowly adopted. How you choose to implement it is your business, not mine. I could tell you 10 different approaches. The point here is mainly that you should be able to move it away from the core, especially if your core is overworked. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jun 27 15:42:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17833 for ; Wed, 27 Jun 2001 15:42:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FKqS-000FO1-00 for multi6-data@psg.com; Wed, 27 Jun 2001 12:19:24 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.30 #1) id 15FKqR-000FNu-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 12:19:23 -0700 Received: (qmail 19563 invoked by uid 100); 27 Jun 2001 19:19:22 -0000 Date: Wed, 27 Jun 2001 15:19:21 -0400 From: Joe Abley To: Tony Hain Cc: multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010627151921.H27658@buddha.home.automagic.org> References: <20010627135355.M27658@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alh-ietf@tndh.net on Wed, Jun 27, 2001 at 11:54:32AM -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, Jun 27, 2001 at 11:54:32AM -0700, Tony Hain wrote: > Joe Abley wrote: > > My point was that it is trivial to affect the routing policy of > > an external organisation by buying transit from them. > Then why couldn't 'popular site' trivially affect the routing policy of 'one > particular provider' to bypass the path? After all they bought transit from > them. They might be able to say to that one provider "don't propogate my advertisements to the promising regional ISP with whom you have peering congestion". However, the result of that is quite possibly that they will become *completely* isolated from that regional ISP, which is not their intention. They want their prefixes to propogate there in a manner which does not cause traffic following them to experience congestion. > All that a site can hope to affect is the 'internal' routing policy of a > service provider, and then only because that is the service being bought. Correct. That is my point. > > If I made the first paragraph "between its transit providers" > > rather than "between transit providers" would thae make it > > clearer? > It would certainly limit the scope of the statement to what is achievable > today. I don't actually think it limits its scope at all, but if it lowers the chance of misunderstanding, I'm happy to put it in. > > The requirement here is that "popular site" should be able > > to multi-home between ISP4 and ISP5 in order to avoid > > congestion between ISP4 and ISP5. > Basically what you are saying here is that 'any site should be able to > acquire services from an arbitrary set of providers'. But the statement in > the draft goes significantly further: > "The multihoming architecture should allow E to ensure that > in normal operation none of its traffic is carried over the > congested interconnection T1-T2." > This implies that any multi-homed E has realtime control of global routing > policies of all other organizations. No it doesn't. It implies that E has a mechanism to influence the way its traffic is carried within each of T1 and T2. > The best that E can hope for is that > traffic from direct customers of T1 & T2 not be carried over the congested > path. No. Traffic from beyond T1 and T2 ultimately has to be carried by T1 and T2 in order to reach E. Once in T1 or T2, the same forwarding decisions will be made for all regardless of the source of the traffic. If T1 never sends traffic to T2 in order to reach E, that holds for all traffic sources. > It may through selective announcements be able to affect some traffic > beyond the direct customers of T1 & T2, but it can't do that reliably on a > global scale. The TE requirements of T1 and T2 are not relevant. > > I still don't see what is unobtainable about the requirement, > > given that it describes motivations for multi-homing that are > > achievable today with v4/CIDR-abuse. > The words used are overly broad compared to actual practice. I don't have a > problem with requiring that current practice be continued, but make sure the > words are not setting us up to require something beyond reality. I don't understand how you reach some of your conclusions (above), and am really not seeing where the "words used are overly broad". If you would like to point out the particular phrases that are causing you to draw some of the conclusions above, that might be useful. Joe From owner-multi6@ops.ietf.org Wed Jun 27 16:57:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27142 for ; Wed, 27 Jun 2001 16:57:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FM0G-000Ias-00 for multi6-data@psg.com; Wed, 27 Jun 2001 13:33:36 -0700 Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by psg.com with esmtp (Exim 3.30 #1) id 15FM0F-000IZQ-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 13:33:35 -0700 Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA35548; Wed, 27 Jun 2001 13:32:55 -0700 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA23660; Wed, 27 Jun 2001 13:33:02 -0700 Message-ID: <3B3A4023.6211A935@hursley.ibm.com> Date: Wed, 27 Jun 2001 15:20:52 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Jon (Taz) Mischo" CC: Sean Doran , ben@layer8.net, multi6@ops.ietf.org Subject: Re: An idea: GxSE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Jon (Taz) Mischo" wrote: > > On Wed, 27 Jun 2001, Brian E Carpenter wrote: > > > > GxSE and NAT are mutually exclusive technologies. > > > > I once characterised 8+8 as "architected NAT", and both GSE and GxSE > > fall into that category - essentially by clearly separating the mutable > > (locator) part from the immutable (identifier) part. I suspect that > > this separation will turn out to be a required property of the multi6 > > solution, and there are a number of ways to achieve it. > > Agreed, I was saying that just to prove how opinionated I am on the > subject. If you read on, though, I THINK I wrote that GxSE basically > takes lessons learned from NAT and applies them and multihoming practices > to v6. This may, however, be what I forgot what I was writing the above. > > I'm really just trying to say that GxSE is being discussed as a way to > avoid having to use true NAT (where the entire address is translated, as > is the definiteion of NAT) by making a similar mechanism part of the > addressing scheme natively. Agreed. I'm not sure the GxSE is the best way to achieve this - once we have the requirements agreed, we need to inspect all the possible solutions carefully (including ones we haven't even talked about yet). Brian From owner-multi6@ops.ietf.org Wed Jun 27 16:57:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27192 for ; Wed, 27 Jun 2001 16:57:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FMNw-000JEX-00 for multi6-data@psg.com; Wed, 27 Jun 2001 13:58:04 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.30 #1) id 15FMNu-000JEP-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 13:58:03 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f5RKwHH04984; Wed, 27 Jun 2001 22:58:17 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 27 Jun 2001 22:58:09 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Brian E Carpenter cc: multi6@ops.ietf.org Subject: Re: requirements draft revision In-Reply-To: <3B39EF3F.909D7CC@hursley.ibm.com> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 27 Jun 2001, Brian E Carpenter wrote: > > If the new way of multihoming requires action (upgrading software) by the > > other end, obviously this will be less effective because the number of sites > > that upgrade their software will always be less than 100%. > And people still use Windows 3.1. We can't make this a killer argument > for host updates - that's exactly why I drafted 3.2.3. Of course at some point some software has to change. But just look at the speed at which IPv6 is being deployed: people DON'T want to update their software if it doesn't benefit THEM immediately. This is exactly the reason why I don't think GxSE is the way to go: it requires software updates in just about everything to work at all. We need something that at least works as a single homed system in every instance and works well within the limits of the software/protocol version environment it lives in. So a current IPv6 host should benefit from newer routers rewriting addresses. And newer IPv6 hosts should be able to survive outages by using multiple IP addresses even if the routers aren't capable of rewriting. Obviously, the optimal situation is reached when all the hosts and routers on both ends are completely up-to-date on all the new protocols. So what we need for a GxSE-like solution would be something where either the end host or a router does all the processing or they share, with every case being a likely possibility. In the first case, a host would have multiple GR addresses and transparently accept a change of destination of incoming packets (the sending side has better information about what works because it (hopefully) gets ICMP messages when a packet can't be delivered). On the other hand, if the host doesn't support the new scheme a router has to act as a "multihoming proxy agent" and mimic regular IP connectivity towards the internal host. Note that the permutations between source and destination addresses when two multihomed sites communicate can grow quickly in such a solution: when both ends have two addresses there are four possible paths, with three addresses each nine. Selecting the best path will be very hard in this situation and even selecting just a reasonable one can be a non-trivial problem. > > Basically, I'm saying the new way of multihoming should be at least as > > attractive to most users as the current way. > In the long term. I'd say: intermediate term. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Wed Jun 27 17:24:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15498 for ; Wed, 27 Jun 2001 17:24:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FMWa-000JZ0-00 for multi6-data@psg.com; Wed, 27 Jun 2001 14:07:00 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.30 #1) id 15FMWZ-000JYu-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 14:07:00 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f5RL7DH05001; Wed, 27 Jun 2001 23:07:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 27 Jun 2001 23:07:05 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Tony Hain cc: multi6@ops.ietf.org Subject: RE: requirements draft revision In-Reply-To: Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 27 Jun 2001, Tony Hain wrote: > > Many organizations, including the networks I've worked on, have > > specific communities that can be used to color prefixes, such > > that the routing policy is changed for those prefixes. > This works within the scope of the community. As soon as it violates some > higher-level policy of an arbitrary third-party though it will be ignored. > My point was simply that multi6 requirements can't be setting us up to do > more than current technology allows. The wording needs to be precise so that > it requires continuing current practice without expanding the scope > unrealistically. I think it is reasonable to require that connectivity to the rest of the world over one transit provider should be unimpaired whatever the connectivity status (good, degraded or non-existent) between two transit providers. (But remember you need this line when your link to one of the transit providers fails!) This is what happens today because a network will prefer to send traffic directly to a customer rather than over another network (because of the lower administrative distance of IGPs and/or the shorter BGP path). So a solution that depends on just one transit provider announcing an aggregate and sending traffic to a second transit provider that doesn't announce a more specific would break this requirement. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Wed Jun 27 17:29:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19150 for ; Wed, 27 Jun 2001 17:29:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FMay-000JlZ-00 for multi6-data@psg.com; Wed, 27 Jun 2001 14:11:32 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.30 #1) id 15FMax-000JlT-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 14:11:32 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 27 Jun 2001 14:11:26 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 853E7FD67E9F40B78916C1D1008FE9E9 for plus 1 more; Wed, 27 Jun 2001 14:11:26 -0700 Reply-To: From: "Tony Hain" To: "Joe Abley" Cc: Subject: RE: requirements draft revision Date: Wed, 27 Jun 2001 14:09:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010627151921.H27658@buddha.home.automagic.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: 06A96094-41184309-8603426C-BE8FF478 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe Abley wrote: > If you would like to point out the particular phrases that > are causing you to draw some of the conclusions above, that > might be useful. By multihoming, an enterprise should be able to protect itself from performance difficulties between transit providers. The multihoming architecture should allow E to ensure ... T1 ---- T2 ---- T3 -- | \_ | _/ \ | \_ | _/ E | \ | / / T4 ---- T5 ---- T6 -- E met the requirement 'By multihoming', but there is nothing they can do to protect themselves from an arbitrary set of 'performance difficulties between transit providers'. Yes they can negotiate with T3 & T6 about what gets announced and where, but that is not sufficient to 'ensure' that some other organization like T5 doesn't override their intended policy. All E can do is express a preference. If others choose to abide that preference so be it, but there is nothing E can do to 'ensure' that outcome unless they have real-time control of everyone else's policy. By requiring the multihoming architecture to allow E to 'ensure' an outcome you are moving it well beyond current practice. Basically take the words you are using and apply them to an arbitrary topology that is outside the scope you are intending to address. If the words are germane but don't return the expected result, they are not precise enough and need to be replaced or removed. Again, I believe the actual requirement you are targeting is 'any site should be able to acquire services from an arbitrary set of providers'. The reasons may be to avoid congestion, or simply lowering latency to a pocket of customers. The precise reason doesn't matter and is really out of scope because that is a policy issue. What matters is that the architecture needs to enable traffic between any site and the customers of a directly attached service provider to be directed over the attachment to that service provider. Tony From owner-multi6@ops.ietf.org Wed Jun 27 18:25:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27781 for ; Wed, 27 Jun 2001 18:25:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FNRT-000MN2-00 for multi6-data@psg.com; Wed, 27 Jun 2001 15:05:47 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.30 #1) id 15FNRS-000MKA-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 15:05:46 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 923A182670; Wed, 27 Jun 2001 18:05:07 -0400 (EDT) Message-Id: <5.1.0.14.2.20010627175639.01ea6850@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Jun 2001 18:01:08 -0400 To: "Jon (Taz) Mischo" From: RJ Atkinson Subject: Re: An idea: GxSE Cc: multi6@ops.ietf.org In-Reply-To: References: <5.1.0.14.2.20010627145034.009f9820@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 15:32 27/06/01, Jon (Taz) Mischo wrote: >> Right, so I'd much rather use that ICMP message, work with any >> IGP, not change any IGP, and not put any extra gorp in the IGP. > >As a former Network Engineer for a few large networks (including one of >the largest ISPs in the history of the US), I can tell you I'd tolerate a >new directive in an IGP better than a whole slew of ICMP messages to every >host every time Joe Blow's route flaps. I believe that you believe that. I also think that Enterprise network engineers often view network issues VERY differently than backbone network engineers. Neither is right or wrong necessarily. The network contexts are really different between a small enterprise, a large enterprise, and any backbone. >ummm? I don't think you understand GxSE. Remind me again, what is the filename on your Internet Draft ? :-) >> I will note that I'm truly not worried about a router >> performing the rewrite over say 10 Gbps Ethernet uplink to an ISP >> at full line rate. Forwarding ASICs are your friend. Other folks >> mileage might vary of course... > >Heh. The point is that ASIC changes mean hardware changes. >That's even more slowly adopted. I'd be startled if multiple vendors couldn't do address rewriting already. It uses roughly the same hardware logic as NAT, so if one has a partially programmable forwarding engine and thought about NAT, one might well have the capability in the ASICs already deployed. Different folks mileage will vary of course. Ran rja@Inet.org From owner-multi6@ops.ietf.org Wed Jun 27 18:35:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04136 for ; Wed, 27 Jun 2001 18:35:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FNat-000Mjp-00 for multi6-data@psg.com; Wed, 27 Jun 2001 15:15:31 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.30 #1) id 15FNat-000Mjd-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 15:15:31 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id RAA21001; Wed, 27 Jun 2001 17:15:41 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 27 Jun 2001 17:15:41 -0500 (CDT) From: "Jon (Taz) Mischo" To: RJ Atkinson cc: multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <5.1.0.14.2.20010627175639.01ea6850@10.30.15.2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 27 Jun 2001, RJ Atkinson wrote: > I also think that Enterprise network engineers often view > network issues VERY differently than backbone network engineers. > Neither is right or wrong necessarily. The network contexts are really > different between a small enterprise, a large enterprise, and any > backbone. I've dealt with all three, rather extensively. I've noticed that often enterprises whose engineers don't "think big" are also the ones whose networks are constantly broken. > >ummm? I don't think you understand GxSE. > > Remind me again, what is the filename on your Internet Draft ? :-) Touche. This really is just conversation, though. A draft will come later, after there are requirements (unless Paul has other ideas? the idea did start with him). > >Heh. The point is that ASIC changes mean hardware changes. > >That's even more slowly adopted. > > I'd be startled if multiple vendors couldn't do address > rewriting already. It uses roughly the same hardware logic as NAT, > so if one has a partially programmable forwarding engine and > thought about NAT, one might well have the capability in the > ASICs already deployed. Different folks mileage will vary of course. This may or may not be true. Just becase rewriting is possible doesn't mean it is possible in this manner, especially since it's not a one to one or many to one relationship, but a decision tree relationship. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jun 27 19:25:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06071 for ; Wed, 27 Jun 2001 19:25:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FO5w-000Nze-00 for multi6-data@psg.com; Wed, 27 Jun 2001 15:47:36 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.30 #1) id 15FO5v-000NzX-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 15:47:36 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id 43ADB823; Thu, 28 Jun 2001 00:47:29 +0200 (CEST) To: rja@inet.org, taz@tazlore.com Subject: Drafts (Re: An idea: GxSE) Cc: multi6@ops.ietf.org Message-Id: <20010627224729.43ADB823@sean.ebone.net> Date: Thu, 28 Jun 2001 00:47:29 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk | A draft will come later, after there are requirements (unless | Paul has other ideas? the idea did start with him). Please don't let the absence of an ended last-call on a req document prevent you from writing and sharing drafts now. Indeed, such drafts may help improve the work-in-progress on the req doc. Sean. From owner-multi6@ops.ietf.org Wed Jun 27 20:04:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02802 for ; Wed, 27 Jun 2001 20:04:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FOnn-00002F-00 for multi6-data@psg.com; Wed, 27 Jun 2001 16:32:55 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.30 #1) id 15FOnm-000029-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 16:32:54 -0700 Received: (qmail 21051 invoked by uid 100); 27 Jun 2001 23:32:52 -0000 Date: Wed, 27 Jun 2001 19:32:52 -0400 From: Joe Abley To: Tony Hain Cc: multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010627193252.Q27658@buddha.home.automagic.org> References: <20010627151921.H27658@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alh-ietf@tndh.net on Wed, Jun 27, 2001 at 02:09:24PM -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, Jun 27, 2001 at 02:09:24PM -0700, Tony Hain wrote: > Joe Abley wrote: > > If you would like to point out the particular phrases that > > are causing you to draw some of the conclusions above, that > > might be useful. > > By multihoming, an enterprise should be able to protect itself from > performance difficulties between transit providers. ... "between _its_ transit providers", I think we agreed. > The multihoming architecture should allow E to ensure ... > > > T1 ---- T2 ---- T3 -- > | \_ | _/ \ > | \_ | _/ E > | \ | / / > T4 ---- T5 ---- T6 -- > > E met the requirement 'By multihoming', but there is nothing they can do to > protect themselves from an arbitrary set of 'performance difficulties > between transit providers'. The only transit providers in that diagram are T3 and T6. > Yes they can negotiate with T3 & T6 about what > gets announced and where, but that is not sufficient to 'ensure' that some > other organization like T5 doesn't override their intended policy. T5 is not a transit provider of E. > All E can > do is express a preference. If others choose to abide that preference so be > it, but there is nothing E can do to 'ensure' that outcome unless they have > real-time control of everyone else's policy. I have already described how E can expect to have exit policy for E's prefixes handled by T3 and T6. > By requiring the multihoming > architecture to allow E to 'ensure' an outcome you are moving it well beyond > current practice. No. > Basically take the words you are using and apply them to an arbitrary > topology that is outside the scope you are intending to address. If the > words are germane but don't return the expected result, they are not precise > enough and need to be replaced or removed. I am still not seeing why you think T[1245] are transit providers of E. > Again, I believe the actual requirement you are targeting is 'any site > should be able to acquire services from an arbitrary set of providers'. No. The requirement is what is written in the draft, and I do not agree that it reduces to that sentence. If a host within E communicates with a host in T3 using a source address delegated from T6, and the multi-homing scheme prohibits E advertising its T6-delegated prefix to T3, then this requirement is not met, for example, since T3 will route to E via T6. > The > reasons may be to avoid congestion, or simply lowering latency to a pocket > of customers. The precise reason doesn't matter and is really out of scope > because that is a policy issue. There is a particular capability here that is common in the network today that we want to preserve. If people are unable to overcome peering congestion between operators in this way, they will find another way, and it will quite probably resemble what what is done today with v4. > What matters is that the architecture needs > to enable traffic between any site and the customers of a directly attached > service provider to be directed over the attachment to that service > provider. I think you're going to need to rephrase that paragraph, because I can't parse it. Joe From owner-multi6@ops.ietf.org Wed Jun 27 21:30:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02381 for ; Wed, 27 Jun 2001 21:30:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FQLs-0004bT-00 for multi6-data@psg.com; Wed, 27 Jun 2001 18:12:12 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.30 #1) id 15FQLj-0004bJ-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 18:12:07 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 27 Jun 2001 18:10:41 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 6EB8BD61F7884920891A688EBE5E7DA0 for plus 1 more; Wed, 27 Jun 2001 18:10:41 -0700 Reply-To: From: "Tony Hain" To: "Joe Abley" Cc: Subject: RE: requirements draft revision Date: Wed, 27 Jun 2001 18:08:45 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010627193252.Q27658@buddha.home.automagic.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: 0CB51C1B-ADAF4E01-97291E66-53BC4E6B Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe Abley wrote: > The only transit providers in that diagram are T3 and T6. According to the definition in the document, all the Tx organizations are transit providers. The fact they don't happen to be attached to E makes no difference to their status as transit providers. > T5 is not a transit provider of E. While E is not a direct customer of T5, that does not mean T5 is not providing transit services for traffic to E, particularly for clients of itself or T4. Revenue and customer/supplier relationship have no connection with the service of connectivity and transiting bits beyond the provider's network. > I have already described how E can expect to have exit policy > for E's prefixes handled by T3 and T6. Yes, and I have described that all the exit policies mean nothing unless the next party honors them. Since E is not a customer why should they? > No. The requirement is what is written in the draft, and I do > not agree that it reduces to that sentence. If a host within > E communicates with a host in T3 using a source address > delegated from T6, and the multi-homing scheme prohibits E > advertising its T6-delegated prefix to T3, then this requirement > is not met, for example, since T3 will route to E via T6. Ah, the core of the problem ... applying an IPv4 mindset and constraints to an IPv6 problem space. There is absolutely no reason for E to expect T3 or T6 to accept and route a prefix from the other. They may be willing to do so, but it is not a strict requirement for IPv6 multihoming to solve the simple scenario you described. If a host within E is communicating with a host in T3, longest-match source address selection rules will cause it to use E's T3 prefix. If E chooses not to provide both prefixes to it's hosts, that is not T3's problem. Now if you are talking about a scenario where T3 & T6 are providing backup for each other's prefix of E for the transit providers beyond, then we are at the point of a substantive requirement and discussion. > There is a particular capability here that is common in the > network today that we want to preserve. If people are unable > to overcome peering congestion between operators in this way, > they will find another way, and it will quite probably resemble > what what is done today with v4. I have no problem with this. All I am looking for is a precise description of current practice so we don't end up with an expectation that an IPv6 solution is required to do far more. Basically the current document reduces to 'if E connects to more than one provider the multihoming architecture will *ensure* that E is able to direct traffic the way it wants at a global scale'. This is a far broader statement than the simple scenario you have for the example, but there is nothing requiring the statement to be restricted to that scenario. > I think you're going to need to rephrase that paragraph, because > I can't parse it. If a host within E communicates with a host in T3 it will use the path between E and T3, likewise for communication with a host within T6 it will use the path between E and T6. Tony From owner-multi6@ops.ietf.org Wed Jun 27 22:04:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26985 for ; Wed, 27 Jun 2001 22:04:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FQwc-0006KJ-00 for multi6-data@psg.com; Wed, 27 Jun 2001 18:50:10 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.30 #1) id 15FQwb-0006KB-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 18:50:09 -0700 Received: (qmail 1651 invoked by uid 100); 28 Jun 2001 01:50:08 -0000 Date: Wed, 27 Jun 2001 21:50:08 -0400 From: Joe Abley To: Tony Hain Cc: multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010627215008.D15973@buddha.home.automagic.org> References: <20010627193252.Q27658@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alh-ietf@tndh.net on Wed, Jun 27, 2001 at 06:08:45PM -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, Jun 27, 2001 at 06:08:45PM -0700, Tony Hain wrote: > Joe Abley wrote: > > The only transit providers in that diagram are T3 and T6. > > According to the definition in the document, all the Tx organizations are > transit providers. The fact they don't happen to be attached to E makes no > difference to their status as transit providers. How about this: A "transit provider", T, of enterprise E is an enterprise which provides connectivity to the Internet for E which extends beyond the part of the Internet operated by T. T and E are directly connected. > > T5 is not a transit provider of E. > > While E is not a direct customer of T5, that does not mean T5 is not > providing transit services for traffic to E, particularly for clients of > itself or T4. Revenue and customer/supplier relationship have no connection > with the service of connectivity and transiting bits beyond the provider's > network. See above. > > I have already described how E can expect to have exit policy > > for E's prefixes handled by T3 and T6. > > Yes, and I have described that all the exit policies mean nothing unless the > next party honors them. Since E is not a customer why should they? See above. > > No. The requirement is what is written in the draft, and I do > > not agree that it reduces to that sentence. If a host within > > E communicates with a host in T3 using a source address > > delegated from T6, and the multi-homing scheme prohibits E > > advertising its T6-delegated prefix to T3, then this requirement > > is not met, for example, since T3 will route to E via T6. > > Ah, the core of the problem ... applying an IPv4 mindset and constraints to > an IPv6 problem space. No -- illustrating how the requirement is not met by a particular multihoming strategy. > There is absolutely no reason for E to expect T3 or > T6 to accept and route a prefix from the other. They may be willing to do > so, but it is not a strict requirement for IPv6 multihoming to solve the > simple scenario you described. If a host within E is communicating with a > host in T3, longest-match source address selection rules will cause it to > use E's T3 prefix. If E chooses not to provide both prefixes to it's hosts, > that is not T3's problem. > > Now if you are talking about a scenario where T3 & T6 are providing backup > for each other's prefix of E for the transit providers beyond, then we are > at the point of a substantive requirement and discussion. We are not presupposing a routing solution. We are simply stating a requirement. > > There is a particular capability here that is common in the > > network today that we want to preserve. If people are unable > > to overcome peering congestion between operators in this way, > > they will find another way, and it will quite probably resemble > > what what is done today with v4. > > I have no problem with this. All I am looking for is a precise description > of current practice so we don't end up with an expectation that an IPv6 > solution is required to do far more. Basically the current document reduces > to 'if E connects to more than one provider the multihoming architecture > will *ensure* that E is able to direct traffic the way it wants at a global > scale'. Well, I don't think it does but it is clear you do :) Does the changed definition above make things better? Joe From owner-multi6@ops.ietf.org Wed Jun 27 23:06:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA11539 for ; Wed, 27 Jun 2001 23:06:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FRzt-0009GC-00 for multi6-data@psg.com; Wed, 27 Jun 2001 19:57:37 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.30 #1) id 15FRzr-0009Fe-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 19:57:36 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 27 Jun 2001 19:57:30 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 9C0EACE1FB1A46E6AE7F02F13B97D587 for plus 1 more; Wed, 27 Jun 2001 19:57:30 -0700 Reply-To: From: "Tony Hain" To: "Joe Abley" Cc: Subject: RE: requirements draft revision Date: Wed, 27 Jun 2001 19:55:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010627215008.D15973@buddha.home.automagic.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: 38772C27-680F404E-87F49470-44BCD7A0 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe Abley wrote: > A "transit provider", T, of enterprise E is an enterprise > which provides connectivity to the Internet for E which > extends beyond the part of the Internet operated by T. T > and E are directly connected. That solves the problem by restricting the definition to match that specific example, but I thought one of the points of multi6 was to address the general problem for all *transit* providers caused by multihomed sites. With this approach there is no definition for the transit providers not connected to E, so when we move on to the next example of things that need to work the definition will no longer fit. > We are not presupposing a routing solution. We are simply > stating a requirement. Oh but you are presupposing a routing solution in that you are expecting one of the transit providers connected to E to provide routing for the site prefix from the other one. While this is an IPv4 requirement, it is optional for IPv6 when the goal is simply keeping the routes straight between the attached providers. Tony From owner-multi6@ops.ietf.org Thu Jun 28 07:17:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11461 for ; Thu, 28 Jun 2001 07:17:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FVGb-000JTW-00 for multi6-data@psg.com; Wed, 27 Jun 2001 23:27:05 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.30 #1) id 15FVGa-000JTQ-00 for multi6@ops.ietf.org; Wed, 27 Jun 2001 23:27:04 -0700 Received: (qmail 3769 invoked by uid 100); 28 Jun 2001 06:26:59 -0000 Date: Thu, 28 Jun 2001 02:26:58 -0400 From: Joe Abley To: Tony Hain Cc: multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010628022658.J15973@buddha.home.automagic.org> References: <20010627215008.D15973@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alh-ietf@tndh.net on Wed, Jun 27, 2001 at 07:55:38PM -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, Jun 27, 2001 at 07:55:38PM -0700, Tony Hain wrote: > Joe Abley wrote: > > A "transit provider", T, of enterprise E is an enterprise > > which provides connectivity to the Internet for E which > > extends beyond the part of the Internet operated by T. T > > and E are directly connected. > > That solves the problem by restricting the definition to match that specific > example, Actually, no -- that's what I always intended the definition to be. Someone two hops away with whom you don't have a direct relationship is not a transit provider, even though they might carry your traffic. They might be a transit provider of your transit provider, however, or a peer of your transit provider. Global transit works through cascades of relationships. > but I thought one of the points of multi6 was to address the > general problem for all *transit* providers caused by multihomed sites. With > this approach there is no definition for the transit providers not connected > to E, so when we move on to the next example of things that need to work the > definition will no longer fit. Transit providers not connected to E are not transit providers of E. > > We are not presupposing a routing solution. We are simply > > stating a requirement. > > Oh but you are presupposing a routing solution in that you are expecting one > of the transit providers connected to E to provide routing for the site > prefix from the other one. That is the mechanism by which this requirement is met in the current multihoming practice with v4. > While this is an IPv4 requirement, it is optional > for IPv6 when the goal is simply keeping the routes straight between the > attached providers. There may be other mechanisms that meet that requirement in a new v6 architecture. Joe From owner-multi6@ops.ietf.org Thu Jun 28 13:44:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28702 for ; Thu, 28 Jun 2001 13:44:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15Fer7-000KY2-00 for multi6-data@psg.com; Thu, 28 Jun 2001 09:41:25 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.30 #1) id 15Fer5-000KXw-00 for multi6@ops.ietf.org; Thu, 28 Jun 2001 09:41:24 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 28 Jun 2001 09:41:18 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 22EEF1976D8647F9A86D4EE4AF55F8B9 for plus 1 more; Thu, 28 Jun 2001 09:41:17 -0700 Reply-To: From: "Tony Hain" To: "Joe Abley" Cc: Subject: RE: requirements draft revision Date: Thu, 28 Jun 2001 09:38:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010628022658.J15973@buddha.home.automagic.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: 83FF2E27-EFCC42A8-90EC4A4A-15B57227 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe Abley wrote: > Someone two hops away with whom you don't have a direct > relationship is not a transit provider, even though they > might carry your traffic. Somehow I don't think this is a globally recognized definition of the term 'transit provider'. It also unnecessarily focuses the discussion on one tiny segment of the problem space. As I recall, the group's charter is to minimize the impact to the entire routing system (read that all transit providers), not just the ones directly attached to multihomed sites. > > > We are not presupposing a routing solution. We are simply > > > stating a requirement. > > ... > That is the mechanism by which this requirement is met in the > current multihoming practice with v4. And it is obvious you don't see the inconsistency between your statements. > There may be other mechanisms that meet that requirement in > a new v6 architecture. How can there be? You keep insisting the requirement as 'the need for every provider to accept and provide internal routing for the prefix of another provider'. That is not the requirement, it is the current mechanism. If you insist that carrying foreign prefixes is the requirement, there can't be any other mechanism by definition. The real requirement is that 'any enterprise is able to acquire services from an arbitrary set of providers, and have a mechanism to keep the routing straight between those providers such that traffic between the enterprise and customers of any one provider will not transit another provider'. Tony From owner-multi6@ops.ietf.org Thu Jun 28 13:44:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28752 for ; Thu, 28 Jun 2001 13:44:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15Ff9w-000LQv-00 for multi6-data@psg.com; Thu, 28 Jun 2001 10:00:52 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.30 #1) id 15Ff9v-000LQi-00 for multi6@ops.ietf.org; Thu, 28 Jun 2001 10:00:51 -0700 Received: (qmail 19990 invoked by uid 100); 28 Jun 2001 17:00:49 -0000 Date: Thu, 28 Jun 2001 13:00:49 -0400 From: Joe Abley To: Tony Hain Cc: multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010628130049.E17315@buddha.home.automagic.org> References: <20010628022658.J15973@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alh-ietf@tndh.net on Thu, Jun 28, 2001 at 09:38:50AM -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, Jun 28, 2001 at 09:38:50AM -0700, Tony Hain wrote: > Joe Abley wrote: > > Someone two hops away with whom you don't have a direct > > relationship is not a transit provider, even though they > > might carry your traffic. > > Somehow I don't think this is a globally recognized definition of the term > 'transit provider'. Well, it's the only definition I have ever heard of in the past six years of working for transit providers. If my definition is not widely used, I'd be happy to hear an alternative. > It also unnecessarily focuses the discussion on one tiny > segment of the problem space. As I recall, the group's charter is to > minimize the impact to the entire routing system (read that all transit > providers), not just the ones directly attached to multihomed sites. By imposing an architecture on just an enterprise and its transit providers, a solution *is* proposed for the entire routing system, in a similar way that an architecture for hop-by-hop routing semantics can facilitate connectivity between hosts that are more than one hop apart. > > > > We are not presupposing a routing solution. We are simply > > > > stating a requirement. > > > ... > > That is the mechanism by which this requirement is met in the > > current multihoming practice with v4. > > And it is obvious you don't see the inconsistency between your statements. Good. > > There may be other mechanisms that meet that requirement in > > a new v6 architecture. > > How can there be? You keep insisting the requirement as 'the need for every > provider to accept and provide internal routing for the prefix of another > provider'. No. I keep insisting the requirement is as stated in the draft. 3.1.3 Performance By multihoming, an enterprise should be able to protect itself from performance difficulties between transit providers. For example, suppose enterprise E obtains transit from transit providers T1 and T2, and there is long-term congestion between T1 and T2. The multihoming architecture should allow E to ensure that in normal operation none of its traffic is carried over the congested interconnection T1-T2. A multi-homed enterprise must also be able to distribute inbound traffic particular multiple transit providers according to the particular network within their enterprise which is sourcing or sinking the traffic. > That is not the requirement, it is the current mechanism. Agreed. > If you > insist that carrying foreign prefixes is the requirement, I don't. > there can't be any > other mechanism by definition. > > The real requirement is that 'any enterprise is able to acquire services > from an arbitrary set of providers, and have a mechanism to keep the routing > straight between those providers such that traffic between the enterprise > and customers of any one provider will not transit another provider'. I don't see how we can require that any enterprise be able to acquire services from any other enterprise. I also don't think we should be presupposing a routing solution. Joe From owner-multi6@ops.ietf.org Fri Jun 29 00:21:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10790 for ; Fri, 29 Jun 2001 00:21:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15Fpm3-000NsY-00 for multi6-data@psg.com; Thu, 28 Jun 2001 21:20:55 -0700 Received: from black-3.dsl.speakeasy.net ([216.231.56.189] helo=shell-beach.layer8.net) by psg.com with smtp (Exim 3.30 #1) id 15Fpm0-000NsS-00 for multi6@ops.ietf.org; Thu, 28 Jun 2001 21:20:52 -0700 Received: (qmail 40012 invoked by uid 1000); 29 Jun 2001 04:16:37 -0000 Date: Thu, 28 Jun 2001 21:16:37 -0700 From: Ben Black To: Tony Hain Cc: Joe Abley , multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010628211637.C39517@layer8.net> References: <20010628022658.J15973@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JgQwtEuHJzHdouWu" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alh-ietf@tndh.net on Thu, Jun 28, 2001 at 09:38:50AM -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk --JgQwtEuHJzHdouWu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 28, 2001 at 09:38:50AM -0700, Tony Hain wrote: > Joe Abley wrote: > > Someone two hops away with whom you don't have a direct > > relationship is not a transit provider, even though they > > might carry your traffic. >=20 > Somehow I don't think this is a globally recognized definition of the term > 'transit provider'. It also unnecessarily focuses the discussion on one t= iny This is absolutely the globally recognized definition. What you might be confusing is the concept of a transit provider with a transit network. A transit network is one which carries traffic which is neither originated from nor destined to addresses within itself. A transit provider is one which maintains peering agreements with other providers to give access from its customers to the customers of those providers. Note that some providers will use other providers for transit for a variety of reasons. Two transit providers exchanging customer traffic does not mean they are using each other "for transit", in the meaning used from a customer's perspective, though they are certainly acting as transit networks. >=20 > The real requirement is that 'any enterprise is able to acquire services > from an arbitrary set of providers, and have a mechanism to keep the rout= ing > straight between those providers such that traffic between the enterprise > and customers of any one provider will not transit another provider'. >=20 The real requirement is that customers be able to control, through=20 whatever mechanism or mechanisms, the flow of traffic. Your statement above is one point in that space, but there are many others in use everyday on the Internet. Ben --JgQwtEuHJzHdouWu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: kWXy7nSOXCFhc2Tk/ydhenfytLujIvjg iQA/AwUBOzwBJGM46bcYfOYxEQK42wCfTIArvNMlMnZJqtKVCX/cURSp1qsAn01Q mJGzlNZXUMx+4RAbIL/sX4Et =vaCw -----END PGP SIGNATURE----- --JgQwtEuHJzHdouWu-- From owner-multi6@ops.ietf.org Fri Jun 29 07:25:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11734 for ; Fri, 29 Jun 2001 07:25:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15Fvnq-000B6Q-00 for multi6-data@psg.com; Fri, 29 Jun 2001 03:47:10 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.30 #1) id 15Fvno-000B6K-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 03:47:09 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f5TAldH08098; Fri, 29 Jun 2001 12:47:39 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 29 Jun 2001 12:47:13 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Tony Li cc: multi6@ops.ietf.org Subject: Re: requirements draft revision In-Reply-To: <15164.20475.466248.770826@redcs1.procket.com> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 29 Jun 2001, Tony Li wrote: > I submit, therefore, that the real, scalable, requirement for the routing > architecture is somewhat different: that the destination domain NOT be able > to technically inject any policy information into the transit domains > whatsoever. If you want a scalable architecture, your requirements should include "scalable" and not "no injection of policy information". Iljitsch From owner-multi6@ops.ietf.org Fri Jun 29 07:25:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11780 for ; Fri, 29 Jun 2001 07:25:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15Fvxx-000BVl-00 for multi6-data@psg.com; Fri, 29 Jun 2001 03:57:37 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.30 #1) id 15Fvxw-000BVf-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 03:57:36 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21311; Fri, 29 Jun 2001 06:56:52 -0400 (EDT) Message-Id: <200106291056.GAA21311@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-multi6-v4-multihoming-00.txt Date: Fri, 29 Jun 2001 06:56:52 -0400 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Multihoming in IPv6 Working Group of the IETF. Title : IPv4 Multihoming Motivation, Practices and Limitations Author(s) : J. Abley, B. Black, V. Gill Filename : draft-ietf-multi6-v4-multihoming-00.txt Pages : 12 Date : 28-Jun-01 Multihoming is an essential component of service for enterprises [3] which are part of the Internet. This draft describes some of the motivations, practices and limitations of multihoming as it is achieved in the IPv4 world today. The context for this discussion is the requirements analysis for site multihoming in IPv6, which is described in a companion draft [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multi6-v4-multihoming-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-multi6-v4-multihoming-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-multi6-v4-multihoming-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010628082704.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-multi6-v4-multihoming-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-multi6-v4-multihoming-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010628082704.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Fri Jun 29 07:32:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16187 for ; Fri, 29 Jun 2001 07:32:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FuyS-0009Mi-00 for multi6-data@psg.com; Fri, 29 Jun 2001 02:54:04 -0700 Received: from flowpoint.procket.com ([209.140.237.1] helo=redcs1.procket.com) by psg.com with esmtp (Exim 3.30 #1) id 15FuyR-0009LS-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 02:54:03 -0700 Received: (from tli@localhost) by redcs1.procket.com (8.9.3/8.9.3) id CAA04890; Fri, 29 Jun 2001 02:52:59 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: redcs1.procket.com: tli set sender to tli@redcs1.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15164.20475.466248.770826@redcs1.procket.com> Date: Fri, 29 Jun 2001 02:52:59 -0700 To: Ben Black Cc: Tony Hain , Joe Abley , multi6@ops.ietf.org Subject: Re: requirements draft revision In-Reply-To: <20010628211637.C39517@layer8.net> References: <20010628022658.J15973@buddha.home.automagic.org> <20010628211637.C39517@layer8.net> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | The real requirement is that customers be able to control, through | whatever mechanism or mechanisms, the flow of traffic. Your statement | above is one point in that space, but there are many others in use | everyday on the Internet. Today's routing architecture provides policy control for inter-domain traffic, but gives complete control over that policy to the source and transit domains along the path. Today's architecture gives NO direct, technical control to the destination. The way that the destination influences transit policy is through the use of external motivation (i.e. cash changing hands) or through the use of advisory information injected into routing. In this latter class, the mechanisms are simply those that take advantage of some side effects in the normal policy computations of the transit domains. Specifically, by injecting a longer prefix, their announcements take priority over aggregated announcements. By padding the AS path, they can make one entry preferable to another. If your real requirement is to extend the policy control of the destination, then you must also accept the fact that there must be distribution about the policy requests of the destination to the transit domains. However, distributing this information is exactly what is causing the indigestion in the routing subsystem today. I submit, therefore, that the real, scalable, requirement for the routing architecture is somewhat different: that the destination domain NOT be able to technically inject any policy information into the transit domains whatsoever. Policy wonks will observe that this causes the destination domain to revert to using cash to influence transit routing policy, thereby eliminating the tragedy of the commons that we live with today. Regards, Tony From owner-multi6@ops.ietf.org Fri Jun 29 12:53:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18655 for ; Fri, 29 Jun 2001 12:53:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G0hV-000MXW-00 for multi6-data@psg.com; Fri, 29 Jun 2001 09:00:57 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.30 #1) id 15G0hU-000MXQ-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 09:00:56 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 29 Jun 2001 09:00:48 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 191CD87F366F4FB2AECFB5B9391C4ADE for plus 2 more; Fri, 29 Jun 2001 09:00:48 -0700 Reply-To: From: "Tony Hain" To: "Ben Black" Cc: "Joe Abley" , Subject: RE: requirements draft revision Date: Fri, 29 Jun 2001 08:57:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010628211637.C39517@layer8.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: E3FB32EC-E1C64B9A-9D922848-4D8E40D1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ben Black wrote: > A transit network is one which carries traffic which is > neither originated from nor destined to addresses within > itself. A transit provider is one which maintains peering > agreements with other providers to give access from its > customers to the customers of those providers. There is absolutely no distinction between those statements! You are mixing the concept of customer with the technical detail of address space. A pair of providers with customers in PI space would fit both of those statements. A pair of providers connecting only dial customers using their space would fit the last one. How does the term transit apply in that case? What you appear to be trying to distinguish between is the network selling dial-access from one selling policy-enabled leased-line services. In the old days when the latter used PI address space, the address based definition made sense, but now that customers are simply punching holes in the provider's block, the address-based distinction is gone. > Note that some providers will use other providers for > transit for a variety of reasons. Absolutely. The question is if the entire chain of providers is using a chain of sub-delegated address space from one end, are they transit providers by this definition? A-B-C-D-E The fact that E maintains peering arrangements so its customers can reach customers of B would make it a transit provider by your second statement, but E's address space came from D, which came from C, which came from B, so according to your first bullet these are transit networks in one direction but not the other. From this and Joe's statements, I believe the intended distinction between 'transit network' and 'transit provider' is actually based on the actions of the connecting enterprise. If that enterprise is further selling access services to other enterprises (therefore it is assumed to be expressing distinct routing policies), then the transit entity is termed a 'network'; when the enterprise simply terminates connections for internal purposes and wants to express global routing policy through the transit entity, then the transit entity is termed a 'provider'. This leaves an obvious missing case, so I assume if the enterprise simply terminates connections for internal purposes and doesn't express policy, then the transit entity is simply called an 'access provider'. Note there is no distinction here about customer relationship, or address space being used. If this is the case, the definition in the document needs to be tightened up to define the actions of the connecting enterprise. Tony From owner-multi6@ops.ietf.org Fri Jun 29 13:29:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20032 for ; Fri, 29 Jun 2001 13:29:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G1Xf-000OlP-00 for multi6-data@psg.com; Fri, 29 Jun 2001 09:54:51 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15G1Xf-000OlI-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 09:54:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15G1Xd-0004so-00; Fri, 29 Jun 2001 09:54:49 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ben Black Cc: Joe Abley , multi6@ops.ietf.org Subject: RE: requirements draft revision References: <20010628211637.C39517@layer8.net> Message-Id: Date: Fri, 29 Jun 2001 09:54:49 -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > A transit network is one which carries traffic which is neither originated > from nor destined to addresses within itself. s/itself/its customers/ > A transit provider is one which maintains peering agreements with other > providers to give access from its customers to the customers of those > providers. nope. a transit provider might have no peering, and purely purchase. e.g. savvis, internap, ... randy From owner-multi6@ops.ietf.org Fri Jun 29 14:23:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22029 for ; Fri, 29 Jun 2001 14:23:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G2ar-0001Jv-00 for multi6-data@psg.com; Fri, 29 Jun 2001 11:02:13 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15G2aq-0001Jm-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 11:02:12 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15G2Zb-0006gS-00; Fri, 29 Jun 2001 11:00:55 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Abley Cc: Ben Black , multi6@ops.ietf.org Subject: Re: requirements draft revision References: <20010628211637.C39517@layer8.net> <20010629135319.Q3425@buddha.home.automagic.org> Message-Id: Date: Fri, 29 Jun 2001 11:00:55 -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > A "transit provider", T, of enterprise E is an enterprise > which provides connectivity to the Internet for E which > extends beyond the part of the Internet operated by T. T > and E are directly connected. i have a more open notion A "transit provider", T, to network N provides N with connectivity to the global internet extending beyond that part of the internet operated by T. T and N may be directly connected, or the relationship may be indirect. randy From owner-multi6@ops.ietf.org Fri Jun 29 14:28:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22165 for ; Fri, 29 Jun 2001 14:28:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G2SM-000112-00 for multi6-data@psg.com; Fri, 29 Jun 2001 10:53:26 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.30 #1) id 15G2SL-0000zm-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 10:53:25 -0700 Received: (qmail 25835 invoked by uid 100); 29 Jun 2001 17:53:19 -0000 Date: Fri, 29 Jun 2001 13:53:19 -0400 From: Joe Abley To: Randy Bush Cc: Ben Black , multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010629135319.Q3425@buddha.home.automagic.org> References: <20010628211637.C39517@layer8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from randy@psg.com on Fri, Jun 29, 2001 at 09:54:49AM -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jun 29, 2001 at 09:54:49AM -0700, Randy Bush wrote: > > A transit network is one which carries traffic which is neither originated > > from nor destined to addresses within itself. > > s/itself/its customers/ > > > A transit provider is one which maintains peering agreements with other > > providers to give access from its customers to the customers of those > > providers. > > nope. a transit provider might have no peering, and purely purchase. > e.g. savvis, internap, ... The last definition I had was this: A "transit provider", T, of enterprise E is an enterprise which provides connectivity to the Internet for E which extends beyond the part of the Internet operated by T. T and E are directly connected. Is this accurate/sufficient? Joe From owner-multi6@ops.ietf.org Fri Jun 29 14:34:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22338 for ; Fri, 29 Jun 2001 14:34:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G2oQ-0001pJ-00 for multi6-data@psg.com; Fri, 29 Jun 2001 11:16:14 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.30 #1) id 15G2oP-0001p8-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 11:16:13 -0700 Received: (qmail 27898 invoked by uid 100); 29 Jun 2001 18:16:11 -0000 Date: Fri, 29 Jun 2001 14:16:11 -0400 From: Joe Abley To: Randy Bush Cc: Ben Black , multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010629141611.V3425@buddha.home.automagic.org> References: <20010628211637.C39517@layer8.net> <20010629135319.Q3425@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from randy@psg.com on Fri, Jun 29, 2001 at 11:00:55AM -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jun 29, 2001 at 11:00:55AM -0700, Randy Bush wrote: > > A "transit provider", T, of enterprise E is an enterprise > > which provides connectivity to the Internet for E which > > extends beyond the part of the Internet operated by T. T > > and E are directly connected. > > i have a more open notion > > A "transit provider", T, to network N provides N with connectivity to the > global internet extending beyond that part of the internet operated by T. > T and N may be directly connected, or the relationship may be indirect. We haven't defined a "network" in this context (I'm assuming "enterprise" will do the trick; "network" hints at routing solutions and we are trying to be general). Also, a transit provider can usefully provide connectivity to some subset of the global internet, as in the case of, uh, some friendly, easy-to-deal-with ISP providing transit to just one soon-to-file- chapter-11 ISP who is difficult to deal with directly. What do you have in mind by the "or the relationship may be indirect" phrase? What particular case are you trying to accommodate? Joe From owner-multi6@ops.ietf.org Fri Jun 29 14:34:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22349 for ; Fri, 29 Jun 2001 14:34:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G2wX-0002D2-00 for multi6-data@psg.com; Fri, 29 Jun 2001 11:24:37 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15G2wW-0002Cu-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 11:24:36 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15G2wV-0007Kj-00; Fri, 29 Jun 2001 11:24:35 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Abley Cc: Ben Black , multi6@ops.ietf.org Subject: Re: requirements draft revision References: <20010628211637.C39517@layer8.net> <20010629135319.Q3425@buddha.home.automagic.org> <20010629141611.V3425@buddha.home.automagic.org> Message-Id: Date: Fri, 29 Jun 2001 11:24:35 -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > We haven't defined a "network" in this context (I'm assuming > "enterprise" will do the trick; "network" hints at routing > solutions and we are trying to be general). > > ... > > What do you have in mind by the "or the relationship may be indirect" > phrase? What particular case are you trying to accommodate? transit providers provide transit to other transit providers. hence the recursion. hence the use of network, not enterprise. randy From owner-multi6@ops.ietf.org Fri Jun 29 15:14:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23453 for ; Fri, 29 Jun 2001 15:14:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G3Ep-0002xw-00 for multi6-data@psg.com; Fri, 29 Jun 2001 11:43:31 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.30 #1) id 15G3Eo-0002xn-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 11:43:30 -0700 Received: (qmail 9301 invoked by uid 100); 29 Jun 2001 18:43:28 -0000 Date: Fri, 29 Jun 2001 14:43:28 -0400 From: Joe Abley To: Randy Bush Cc: Ben Black , multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010629144328.Z3425@buddha.home.automagic.org> References: <20010628211637.C39517@layer8.net> <20010629135319.Q3425@buddha.home.automagic.org> <20010629141611.V3425@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from randy@psg.com on Fri, Jun 29, 2001 at 11:24:35AM -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jun 29, 2001 at 11:24:35AM -0700, Randy Bush wrote: > > We haven't defined a "network" in this context (I'm assuming > > "enterprise" will do the trick; "network" hints at routing > > solutions and we are trying to be general). > > > > ... > > > > What do you have in mind by the "or the relationship may be indirect" > > phrase? What particular case are you trying to accommodate? > > transit providers provide transit to other transit providers. hence the > recursion. hence the use of network, not enterprise. Is a transit provider not itself an enterprise? I was assuming it was. Joe From owner-multi6@ops.ietf.org Fri Jun 29 15:19:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23570 for ; Fri, 29 Jun 2001 15:19:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G3oA-0004WS-00 for multi6-data@psg.com; Fri, 29 Jun 2001 12:20:02 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.30 #1) id 15G3o9-0004WG-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 12:20:02 -0700 Received: (qmail 29089 invoked by uid 100); 29 Jun 2001 19:20:01 -0000 Date: Fri, 29 Jun 2001 15:20:00 -0400 From: Joe Abley To: Randy Bush Cc: Ben Black , multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010629152000.F3425@buddha.home.automagic.org> References: <20010629135319.Q3425@buddha.home.automagic.org> <20010629141611.V3425@buddha.home.automagic.org> <20010629144328.Z3425@buddha.home.automagic.org> <20010629145433.A3425@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from randy@psg.com on Fri, Jun 29, 2001 at 12:16:43PM -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jun 29, 2001 at 12:16:43PM -0700, Randy Bush wrote: > >>> Is a transit provider not itself an enterprise? I was assuming it > >>> was. > >> i try not to use the same noun to refer to two different concepts > >> within the same sentence. intentional puns excepted, of course. > > I don't mean "enterprise" to have the meaning "customer". I mean it > > like "autonomous system", but without the routing/BGP connotations. > > apologies. my confusion. i thought you were trying to communicate, > but you seem to care more about being right. I was just trying to make the definition clear. Seems there is some confusion about what I meant. *shrug* From owner-multi6@ops.ietf.org Fri Jun 29 15:19:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23586 for ; Fri, 29 Jun 2001 15:19:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G3Gl-00036V-00 for multi6-data@psg.com; Fri, 29 Jun 2001 11:45:31 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15G3Gk-00036P-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 11:45:30 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15G3Gj-0007un-00; Fri, 29 Jun 2001 11:45:29 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Abley Cc: Ben Black , multi6@ops.ietf.org Subject: Re: requirements draft revision References: <20010628211637.C39517@layer8.net> <20010629135319.Q3425@buddha.home.automagic.org> <20010629141611.V3425@buddha.home.automagic.org> <20010629144328.Z3425@buddha.home.automagic.org> Message-Id: Date: Fri, 29 Jun 2001 11:45:29 -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Is a transit provider not itself an enterprise? I was assuming it > was. i try not to use the same noun to refer to two different concepts within the same sentence. intentional puns excepted, of course. randy From owner-multi6@ops.ietf.org Fri Jun 29 15:20:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23648 for ; Fri, 29 Jun 2001 15:20:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G3bs-0003vi-00 for multi6-data@psg.com; Fri, 29 Jun 2001 12:07:20 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.30 #1) id 15G3br-0003vU-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 12:07:19 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 29 Jun 2001 12:07:18 -0700 Message-ID: <008a01c100ce$b79f2dd0$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "Jim Bound" Cc: "Brian E Carpenter" , "Randy Bush" , References: Subject: Re: An idea: GxSE Date: Fri, 29 Jun 2001 12:07:18 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 29 Jun 2001 19:07:18.0706 (UTC) FILETIME=[B79FF120:01C100CE] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'll do it. PF ----- Original Message ----- From: "Jon (Taz) Mischo" To: "Jim Bound" Cc: "Brian E Carpenter" ; "Randy Bush" ; Sent: Tuesday, June 26, 2001 1:07 AM Subject: Re: An idea: GxSE > It was Paul's idea, so initially, I'd say it would be appropriate for him > to. I had some ideas I kind of tossed into the ring that I'd be happy to > work on, but I must defer to Paul, as it's his brainchild :) > > -Taz > > On Mon, 25 Jun 2001, Jim Bound wrote: > > > could you or Paul take a stab at taking GxSE and extracting the reqs its > > solves and we an put those in our reqs definition with other reqs. > > > > I do think it wise we have reqs and then solutions. > > > > > > /jim > > "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) > > > > > > On Mon, 25 Jun 2001, Jon (Taz) Mischo wrote: > > > > > On Mon, 25 Jun 2001, Brian E Carpenter wrote: > > > > > > > Randy, I suggested some very precise requirements text to take account of the > > > > fact that there is a lot of running and shipped code in existing products that > > > > is simply not going to get rewritten that quickly. Like it or not, multi6 > > > > has to coexist with vanilla IPv6, and that generates its own set of > > > > requirements. > > > > > > Brian, if we can make something like GxSE work with vanilla v6, however, > > > that should satisfy everyone. Instead of clobbering the discussion, I > > > think we should expand it. There must be a happy medium. > > > > > > -Taz > > > > > > -- > > > "Be liberal in what you accept, > > > and conservative in what you send.." > > > --Jon Postel (1943-1998) RFC 1122, October 1989 > > > > > > > > > > > > -- > "Be liberal in what you accept, > and conservative in what you send." > --Jon Postel (1943-1998) RFC 1122, October 1989 > > > From owner-multi6@ops.ietf.org Fri Jun 29 15:22:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23666 for ; Fri, 29 Jun 2001 15:22:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G3jK-0004F3-00 for multi6-data@psg.com; Fri, 29 Jun 2001 12:15:02 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.30 #1) id 15G3jI-0004Eo-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 12:15:00 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 29 Jun 2001 12:15:00 -0700 Message-ID: <009f01c100cf$cacae790$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: , "RJ Atkinson" References: <200106221746.f5MHkxG451082@jurassic.eng.sun.com> <5.1.0.14.2.20010623205501.00acc2a0@10.30.15.2> Subject: Re: GxSE & ESP/AH Date: Fri, 29 Jun 2001 12:15:00 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 29 Jun 2001 19:15:00.0359 (UTC) FILETIME=[CACA9970:01C100CF] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > architecture for The Internet. The right answer has always been > to use a topologically-independent namespace for ESP/AH purposes, > but no such namespace exists and is widely deployed today. Note > well that DNS does NOT work for this because a FQDN does NOT uniquely > name a single TCP/IP stack -- instead an FQDN quite often names a > service or content (e.g. www.cnn.com is NOT a system, but rather a > cluster of servers with a middle box in front). > The fact that DNS does not *always* uniquely name a single TCP/IP stack does not mean that it never does, and that when it does it couldn't be used to uniquely identify the host. Thinking off the top of my head, what you would need is for www.cnn.com type hosts to have multiple FQDNs, at least one of them unique, and it would have to know it was unique so that it could use it for identification. Now I'm sure y'all have thought of this, so there must be some gotcha's in there. Perhaps Ran we could find some nice pub in London where you could explain it all to me... PF From owner-multi6@ops.ietf.org Fri Jun 29 15:23:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23715 for ; Fri, 29 Jun 2001 15:23:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G3PY-0003QH-00 for multi6-data@psg.com; Fri, 29 Jun 2001 11:54:36 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.30 #1) id 15G3PW-0003Q8-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 11:54:35 -0700 Received: (qmail 3403 invoked by uid 100); 29 Jun 2001 18:54:33 -0000 Date: Fri, 29 Jun 2001 14:54:33 -0400 From: Joe Abley To: Randy Bush Cc: Ben Black , multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010629145433.A3425@buddha.home.automagic.org> References: <20010628211637.C39517@layer8.net> <20010629135319.Q3425@buddha.home.automagic.org> <20010629141611.V3425@buddha.home.automagic.org> <20010629144328.Z3425@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from randy@psg.com on Fri, Jun 29, 2001 at 11:45:29AM -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jun 29, 2001 at 11:45:29AM -0700, Randy Bush wrote: > > Is a transit provider not itself an enterprise? I was assuming it > > was. > > i try not to use the same noun to refer to two different concepts > within the same sentence. intentional puns excepted, of course. I don't mean "enterprise" to have the meaning "customer". I mean it like "autonomous system", but without the routing/BGP connotations. An "enterprise" is an entity autonomously operating a network using TCP/IP and, in particular, determining the addressing plan and address assignments within that network. Consider: A --- B --- C | | D E A, B, C, D are all enterprises. B, E are transit providers of C. A, D are transit providers of B. Both C and B are multi-homed. If C has customers, then C is a transit provider for those customers. Joe From owner-multi6@ops.ietf.org Fri Jun 29 15:34:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23877 for ; Fri, 29 Jun 2001 15:34:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G3kz-0004Js-00 for multi6-data@psg.com; Fri, 29 Jun 2001 12:16:45 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15G3ky-0004Jm-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 12:16:44 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15G3kx-0008ko-00; Fri, 29 Jun 2001 12:16:43 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Abley Cc: Ben Black , multi6@ops.ietf.org Subject: Re: requirements draft revision References: <20010628211637.C39517@layer8.net> <20010629135319.Q3425@buddha.home.automagic.org> <20010629141611.V3425@buddha.home.automagic.org> <20010629144328.Z3425@buddha.home.automagic.org> <20010629145433.A3425@buddha.home.automagic.org> Message-Id: Date: Fri, 29 Jun 2001 12:16:43 -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> Is a transit provider not itself an enterprise? I was assuming it >>> was. >> i try not to use the same noun to refer to two different concepts >> within the same sentence. intentional puns excepted, of course. > I don't mean "enterprise" to have the meaning "customer". I mean it > like "autonomous system", but without the routing/BGP connotations. apologies. my confusion. i thought you were trying to communicate, but you seem to care more about being right. From owner-multi6@ops.ietf.org Fri Jun 29 15:53:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24355 for ; Fri, 29 Jun 2001 15:53:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G42K-00054H-00 for multi6-data@psg.com; Fri, 29 Jun 2001 12:34:40 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.30 #1) id 15G42J-00054B-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 12:34:39 -0700 Received: from tnpfrancis ([10.10.3.80]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 29 Jun 2001 12:34:38 -0700 Message-ID: <00c801c100d2$8946b850$50030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Jon \(Taz\) Mischo" , "RJ Atkinson" Cc: References: <5.1.0.14.2.20010627145034.009f9820@10.30.15.2> <5.1.0.14.2.20010627175639.01ea6850@10.30.15.2> Subject: A different idea (was Re: An idea: GxSE) Date: Fri, 29 Jun 2001 12:34:38 -0700 Organization: TAHOE Networks 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 29 Jun 2001 19:34:38.0936 (UTC) FILETIME=[89472D80:01C100D2] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > >ummm? I don't think you understand GxSE. > > Remind me again, what is the filename on your Internet Draft ? :-) > Taz, I think it would be good if you come up with a different name for what you are thinking about (GxSE+R or something :-), because for me there is a qualitative jump between involving routing and not involving routing. This is not to say that what you are talking about is bad, I just don't want people to lose the distinction. PF From owner-multi6@ops.ietf.org Fri Jun 29 15:55:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24383 for ; Fri, 29 Jun 2001 15:54:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G424-000542-00 for multi6-data@psg.com; Fri, 29 Jun 2001 12:34:24 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.30 #1) id 15G423-00053t-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 12:34:23 -0700 Received: (qmail 30343 invoked by uid 100); 29 Jun 2001 19:34:22 -0000 Date: Fri, 29 Jun 2001 15:34:22 -0400 From: Joe Abley To: Tony Hain Cc: Randy Bush , Ben Black , multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010629153421.H3425@buddha.home.automagic.org> References: <20010629145433.A3425@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alh-ietf@tndh.net on Fri, Jun 29, 2001 at 12:20:03PM -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jun 29, 2001 at 12:20:03PM -0700, Tony Hain wrote: > Joe Abley wrote: > > An "enterprise" is an entity autonomously operating a > > network using TCP/IP and, in particular, determining the > > addressing plan and address assignments within that network. > > > > Consider: > > > > > > A --- B --- C > > | | > > D E > > > > A, B, C, D are all enterprises. B, E are transit providers of C. > > A, D are transit providers of B. Both C and B are multi-homed. > > > > If C has customers, then C is a transit provider for > > those customers. > > Is C a transit provider if the customer is receiving a /27, but simply > defaulting to C's routing policies? Yes. If a customer of C can reach the rest of the internet through C, then C is a transit provider of that customer. Here's the updated diagram: A --- B --- C --- F | | D E F is the customer of C. > What is the difference between that and > using a dial-in NAT to map 10/8 through a single address received from C? I don't understand the question. It's the fact that C is providing connectivity to the internet beyond C that makes it a transit provider. I don't understand what addressing and/or the presence of NAT has to do with it in the general case. > They both fit the definition of Enterprise here. Yes. A, B, C, D, E and F are all enterprises, according to what I meant to convey in the text. If we can make things clearer by introducing a new term for "an enterprise which has a transit provider", as Randy seemed to be saying, then that's cool. We can do that. > In both cases the address > space and routing policies presented to B & E belong to C, so what makes C a > 'transit' provider? The fact that C provides internet connectivity for F. Joe From owner-multi6@ops.ietf.org Fri Jun 29 15:57:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24430 for ; Fri, 29 Jun 2001 15:57:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G3rs-0004bb-00 for multi6-data@psg.com; Fri, 29 Jun 2001 12:23:52 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.30 #1) id 15G3rr-0004bV-00; Fri, 29 Jun 2001 12:23:51 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 29 Jun 2001 12:23:37 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 005214F9821742E8946E645A9FF2AB79 for plus 3 more; Fri, 29 Jun 2001 12:23:37 -0700 Reply-To: From: "Tony Hain" To: "Joe Abley" , "Randy Bush" Cc: "Ben Black" , Subject: RE: requirements draft revision Date: Fri, 29 Jun 2001 12:20:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010629145433.A3425@buddha.home.automagic.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: 241D2CD7-EB8E467E-9C0E9C12-26800AC1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe Abley wrote: > An "enterprise" is an entity autonomously operating a > network using TCP/IP and, in particular, determining the > addressing plan and address assignments within that network. > > Consider: > > > A --- B --- C > | | > D E > > A, B, C, D are all enterprises. B, E are transit providers of C. > A, D are transit providers of B. Both C and B are multi-homed. > > If C has customers, then C is a transit provider for > those customers. Is C a transit provider if the customer is receiving a /27, but simply defaulting to C's routing policies? What is the difference between that and using a dial-in NAT to map 10/8 through a single address received from C? They both fit the definition of Enterprise here. In both cases the address space and routing policies presented to B & E belong to C, so what makes C a 'transit' provider? From owner-multi6@ops.ietf.org Fri Jun 29 17:26:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25581 for ; Fri, 29 Jun 2001 17:26:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G5XZ-0008am-00 for multi6-data@psg.com; Fri, 29 Jun 2001 14:11:01 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.30 #1) id 15G5XY-0008aa-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 14:11:00 -0700 Received: (qmail 10561 invoked by uid 100); 29 Jun 2001 21:10:53 -0000 Date: Fri, 29 Jun 2001 17:10:53 -0400 From: Joe Abley To: Tony Hain Cc: Randy Bush , Ben Black , multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010629171052.A26708@buddha.home.automagic.org> References: <20010629153421.H3425@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alh-ietf@tndh.net on Fri, Jun 29, 2001 at 01:36:31PM -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jun 29, 2001 at 01:36:31PM -0700, Tony Hain wrote: > The reason I have been hammering on this is there are some underlying > assumptions everyone has about what these terms mean, and buried in those > assumptions are mechanisms for what needs to happen to make things work. I agree, if we're going to have definitions of the terms we use in the requirements doc, we need to have them defined clearly. I have been trying to make the definitions as solution-neutral as possible. > The reason for the NAT question was trying to distinguish the difference > between an individual dialing in vs. a larger organization. Basically, what > does F managing address space have to do with the discussion of C being a > transit or not? The idea was to re-use an established term (that definition comes from RFC1918) as a substitute for "autonomous system" which is the term used in the previous draft, and which implies routing and BGP. The reference to address space makes more sense in an RFC1918 context than in this one, perhaps, but the kind of entity I wanted to use the word "enterprise" to refer to is the same, I think. > Does any collection of routed subnets constitute an > 'Enterprise'? No. "Any collection of routed subnets" could mean anything, from a crossover cable to the entire Internet. The definition of "enterprise" used in the draft is much narrower. > If so do we care about all of them, or only the ones that are > trying to punch a policy through C? Is there a way to distinguish those > cases? The word "enterprise" is only really being used to describe an entity which is able to multi-home. We need to call those entities something. That's not an adquate description, however, since we need "enterprise" in order to defined "multi-home". "transit provider" is a role that an enterprise may play in relation to another enterprise: that of providing connectivity to the Internet. > The fundamental point I was getting to with that last set of questions was > trying to really nail the definition of 'transit'. The last line of your > response implies single directionality. Why is C not a transit provider of > B? (hint: the term 'customer' may not appear in the answer) Heh :) I take your point. I guess C *is* a transit provider of B by the definition in the draft. How about if we s/to the Internet/to the global Internet/ as Randy suggested? > If the Internet were a single rooted tree the single directionality > definition would work, but the Internet is a mesh, so the definition is a > mess. Are you really trying to identify a term for the set of transit > networks where one of the attached parties is a stub? The Internet is, in general a mesh, but in practice it's rarely difficult to identify who is "upstream" and who is "downstream". If we insert the word "global" as above, I think the definition will be very familiar to most operators. To drill the concept home, we could always add some diagrams. On the other hand, if you have a better definition, let's hear it. Joe From owner-multi6@ops.ietf.org Fri Jun 29 18:10:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26189 for ; Fri, 29 Jun 2001 18:10:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G6TM-000Ahv-00 for multi6-data@psg.com; Fri, 29 Jun 2001 15:10:44 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.30 #1) id 15G6TL-000Ahn-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 15:10:43 -0700 Received: (qmail 5257 invoked by uid 100); 29 Jun 2001 22:10:42 -0000 Date: Fri, 29 Jun 2001 18:10:41 -0400 From: Joe Abley To: multi6@ops.ietf.org Subject: [jabley@automagic.org: unscientific multi-homing survey: results] Message-ID: <20010629181041.I26708@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-multi6@ops.ietf.org Precedence: bulk I sent some questions about multi-homing to the nanog list earlier this week, and a few people replied. This is a summary. This is extremely non-rigorous, but might give a tiny bit of insight into something, maybe. ----- Forwarded message from Joe Abley ----- Delivered-To: jabley-nanog@automagic.org Delivered-To: nanog-outgoing@trapdoor.merit.edu Delivered-To: nanog@trapdoor.merit.edu Delivered-To: nanog@merit.edu Date: Fri, 29 Jun 2001 17:50:09 -0400 From: Joe Abley To: nanog@merit.edu Subject: unscientific multi-homing survey: results User-Agent: Mutt/1.2.5i Precedence: bulk Errors-To: owner-nanog-outgoing@merit.edu X-Loop: nanog Results of my unscientific straw poll for multi-homed operators, as requested by a few people. Some people gave multiple answers to questions, and some didn't answer particular questions at all. Figures in brackets indicate frequency of particular responses. Like I said, unscientific :) Thanks to those who sent me mail. Joe On Tue, Jun 26, 2001 at 09:15:09AM -0400, Joe Abley wrote: > If you currently multi-home between two or more providers using IPv4: > > + why do you do it? What are the high-level goals you are hoping to achieve? > Are you finding that you are achieving them? redundancy (3) load-balancing (2) "shorter paths", performance, better throughput for users (4) geographic redundancy (2) provider redundancy (3) we are achieving these objectives (7) > + how often does your traffic shift between transit providers due to > a failure of some kind triggering a re-homing? a couple of times per day (1) once per week (1) once per month (1) a couple of times per month (2) we don't notice when it shifts (1) rarely (1) once per six months per circuit (1) > + how often do you manually shift traffic, and why? Just inbound traffic? > Or outbound too? never (1) normally never (1) once per month (1) occasionally (1) when we get complaints from specific netblock/asns that we can fix (1) when we need to due to transient heavy traffic loads (e.g. a promotion) (1) rarely (three or four times a year) (1) to rebalance costs after some kind of DoS attack (1) (never) because we are overprovisioned with capacity and traffic shifting isn't necessary (1) to optimise use of various peering links (1) manually setting best paths for various ASes (where BGP doesn't see the best path) (1) to avoid some specific poor connectivity on a short path (1) both inbound and outbound (2) > + what impact does a manual or automatic shift in traffic between providers > have to your users? Do their TCP sessions break? Or do you think they > normally stay alive, maybe after a delay? What makes you think this? people don't normally notice the transition (1) transparent if done right (1) stuff breaks a bit, but most TCP sessions remain up (1) minimal impact (1) for 90% of people the sessions sit for a while and then resume, based on feedback in a support forum (1) there is a several minute delay as the BGP tables across the internal core routers adjust (1) VPN users get kicked out when there is a transition, since we don't have provider-independent space and the addresses associated with the down provider become unreachable (1) most traffic is HTTP which is not really affected as long is there isn't too much flapping (1) assume all drop and take any that don't as a bonus (1) no detectable effect (1) we have never had a ticket opened which resolved to TCP session breakage due to a re-homing transition (1) > + what is *bad* about the way that multi-homing works in IPv4? need more control of incoming traffic (1) hard to limit incoming via upstream, although outgoing preference is easy (1) nothing that needs fixing at layer 3 (1) withdrawing and advertersing routes socks the network too much (1) synchronisation takes too long, and sucks up too much router cpu (1) nothing (1) bgp is unintelligent, and requires too much manual tweaking to find the "best" route (1) finding providers which will let you multi-home is hard (1) needing provider-independent address space (1) it can get ugly (1) router vendors need to make more boxes with more memory (1) i would like to have confidence in using RRs more (1) having to trust and cooperate with your peers (1) bgp convergence sucks (1) > + what is good about it? it works (4) it can be done using lots of devices "besides just cisco" (1) it's pretty obvious how it works, and even level-1 ticket takers at backbone providers understand it most of the time (1) it allows us to increase performance, and we like redundancy (1) "The redundancy! The multiple paths! The ability to choose." (1) reliability and shorter paths (1) ----- End forwarded message ----- From owner-multi6@ops.ietf.org Fri Jun 29 20:12:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28018 for ; Fri, 29 Jun 2001 20:12:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G8Nn-000Fqv-00 for multi6-data@psg.com; Fri, 29 Jun 2001 17:13:07 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.30 #1) id 15G8Nm-000Fqp-00; Fri, 29 Jun 2001 17:13:06 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id TAA24528; Fri, 29 Jun 2001 19:13:15 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Fri, 29 Jun 2001 19:13:15 -0500 (CDT) From: "Jon (Taz) Mischo" To: Joe Abley cc: Tony Hain , Randy Bush , Ben Black , multi6@ops.ietf.org Subject: Re: requirements draft revision In-Reply-To: <20010629153421.H3425@buddha.home.automagic.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 29 Jun 2001, Joe Abley wrote: > I don't understand the question. It's the fact that C is providing > connectivity to the internet beyond C that makes it a transit provider. > I don't understand what addressing and/or the presence of NAT has to > do with it in the general case. No, it's the fact that C will route _any_ of its customers' traffic to either its destination or to an egress point nearer (usually) its destination that makes it a transit provider. The word any is the key. A peer will route any traffic you send it that is destined for its own network, and sometimes to other agreed upon networks. A transit provider routes you to EVERYTHING. Is it clearer, now? -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Fri Jun 29 20:23:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28400 for ; Fri, 29 Jun 2001 20:23:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G8KF-000Fe9-00 for multi6-data@psg.com; Fri, 29 Jun 2001 17:09:27 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.30 #1) id 15G8KF-000Fdp-00; Fri, 29 Jun 2001 17:09:27 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id TAA24518; Fri, 29 Jun 2001 19:09:36 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Fri, 29 Jun 2001 19:09:36 -0500 (CDT) From: "Jon (Taz) Mischo" To: Joe Abley cc: Randy Bush , Ben Black , multi6@ops.ietf.org Subject: Re: requirements draft revision In-Reply-To: <20010629152000.F3425@buddha.home.automagic.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk You mean administrative domain. We call them networks, but you can call it an administrative domain. That means a portion of a network controlled by the same body. Mind you, everyone will just say, "Oh, you mean a network." I find it amusing that you're trying very hard to define something while avoiding defining it as what it is. It's like trying to describe a McIntosh apple while avoiding calling in an apple entirely, and avoiding any correlation to an apple. -Taz On Fri, 29 Jun 2001, Joe Abley wrote: > On Fri, Jun 29, 2001 at 12:16:43PM -0700, Randy Bush wrote: > > >>> Is a transit provider not itself an enterprise? I was assuming it > > >>> was. > > >> i try not to use the same noun to refer to two different concepts > > >> within the same sentence. intentional puns excepted, of course. > > > I don't mean "enterprise" to have the meaning "customer". I mean it > > > like "autonomous system", but without the routing/BGP connotations. > > > > apologies. my confusion. i thought you were trying to communicate, > > but you seem to care more about being right. > > I was just trying to make the definition clear. Seems there is > some confusion about what I meant. > > *shrug* > > -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Fri Jun 29 20:24:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28440 for ; Fri, 29 Jun 2001 20:24:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G802-000ElV-00 for multi6-data@psg.com; Fri, 29 Jun 2001 16:48:34 -0700 Received: from black-3.dsl.speakeasy.net ([216.231.56.189] helo=shell-beach.layer8.net) by psg.com with smtp (Exim 3.30 #1) id 15G801-000ElN-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 16:48:33 -0700 Received: (qmail 57332 invoked by uid 1000); 29 Jun 2001 23:44:24 -0000 Date: Fri, 29 Jun 2001 16:44:24 -0700 From: Ben Black To: Randy Bush Cc: Joe Abley , multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010629164424.A57256@layer8.net> References: <20010628211637.C39517@layer8.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from randy@psg.com on Fri, Jun 29, 2001 at 09:54:49AM -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 29, 2001 at 09:54:49AM -0700, Randy Bush wrote: > > A transit network is one which carries traffic which is neither origina= ted > > from nor destined to addresses within itself. >=20 > s/itself/its customers/ >=20 > > A transit provider is one which maintains peering agreements with other > > providers to give access from its customers to the customers of those > > providers. >=20 > nope. a transit provider might have no peering, and purely purchase. > e.g. savvis, internap, ... >=20 "Note that some providers will use other providers for transit for a=20 variety of reasons." Ben --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: XbVl/NnjccTcSZXBoI8vX92sjT5srADJ iQA/AwUBOz0S12M46bcYfOYxEQJW0ACePt0YCgot9qekbwFm9z9gIxjVTSwAoPy1 36Pf6UdjLYTo3TQ0zwIm0Y+W =2/2c -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-multi6@ops.ietf.org Fri Jun 29 21:24:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29495 for ; Fri, 29 Jun 2001 21:24:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G9Js-000HbC-00 for multi6-data@psg.com; Fri, 29 Jun 2001 18:13:08 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.30 #1) id 15G9Jr-000Hb3-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 18:13:07 -0700 Received: (qmail 23589 invoked by uid 100); 30 Jun 2001 01:13:06 -0000 Date: Fri, 29 Jun 2001 21:13:06 -0400 From: Joe Abley To: "Jon \(Taz\) Mischo" Cc: Randy Bush , Ben Black , multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010629211305.L26708@buddha.home.automagic.org> References: <20010629152000.F3425@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from taz@tazlore.com on Fri, Jun 29, 2001 at 07:09:36PM -0500 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jun 29, 2001 at 07:09:36PM -0500, Jon (Taz) Mischo wrote: > You mean administrative domain. We call them networks, but you can call > it an administrative domain. That means a portion of a network controlled > by the same body. > > Mind you, everyone will just say, "Oh, you mean a network." I find it > amusing that you're trying very hard to define something while avoiding > defining it as what it is. It's like trying to describe a McIntosh apple > while avoiding calling in an apple entirely, and avoiding any correlation > to an apple. We could call it a site, a network, an enterprise, a provider, a subscriber, an autonomous system, a domain, an area, an organisation, a node, a backbone, and probably lots of other things. All those terms are heavily overloaded ("network", arguably, more than most). The reason for choosing "enterprise" was that there was an existing definition in RFC1918 that seemed to fit. I called it an "autonomous system" to start with, and the reaction to that was that we needed to drop the routing connotation. I'm not avoiding "network" for any particular reason, although that's not what I'd call it in general conversation. I really don't think it matters what we call it, as long as we know what we mean. If we call it a "network", we still have to define what we mean by that in this context. "Enterprise" doesn't seem like such a bad name to me, but like I say, I don't really care what we use :) Joe From owner-multi6@ops.ietf.org Fri Jun 29 21:27:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29518 for ; Fri, 29 Jun 2001 21:27:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G9NX-000Hl0-00 for multi6-data@psg.com; Fri, 29 Jun 2001 18:16:55 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org ident=qmailr) by psg.com with smtp (Exim 3.30 #1) id 15G9NW-000Hkq-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 18:16:55 -0700 Received: (qmail 26277 invoked by uid 100); 30 Jun 2001 01:16:53 -0000 Date: Fri, 29 Jun 2001 21:16:53 -0400 From: Joe Abley To: "Jon \(Taz\) Mischo" Cc: Tony Hain , Randy Bush , Ben Black , multi6@ops.ietf.org Subject: Re: requirements draft revision Message-ID: <20010629211653.M26708@buddha.home.automagic.org> References: <20010629153421.H3425@buddha.home.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from taz@tazlore.com on Fri, Jun 29, 2001 at 07:13:15PM -0500 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jun 29, 2001 at 07:13:15PM -0500, Jon (Taz) Mischo wrote: > On Fri, 29 Jun 2001, Joe Abley wrote: > > > I don't understand the question. It's the fact that C is providing > > connectivity to the internet beyond C that makes it a transit provider. > > I don't understand what addressing and/or the presence of NAT has to > > do with it in the general case. > > No, it's the fact that C will route _any_ of its customers' traffic to We were avoiding the use of "customer", I think, in the interests of finding a technical description as opposed to a commercial one. > either its destination or to an egress point nearer (usually) its > destination that makes it a transit provider. The word any is the key. A > peer will route any traffic you send it that is destined for its own > network, and sometimes to other agreed upon networks. A transit provider > routes you to EVERYTHING. Right. Isn't this encapsulated in Randy's use of "global"? Joe From owner-multi6@ops.ietf.org Fri Jun 29 21:30:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29544 for ; Fri, 29 Jun 2001 21:30:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G8sV-000Gmb-00 for multi6-data@psg.com; Fri, 29 Jun 2001 17:44:51 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.30 #1) id 15G8sR-000GmN-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 17:44:48 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 29 Jun 2001 16:43:42 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id C29B8FB3AEAF4B9AB25A183C27ADD886 for plus 3 more; Fri, 29 Jun 2001 16:43:42 -0700 Reply-To: From: "Tony Hain" To: "Joe Abley" Cc: "Randy Bush" , "Ben Black" , Subject: RE: requirements draft revision Date: Fri, 29 Jun 2001 16:39:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010629171052.A26708@buddha.home.automagic.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: 51633561-1CD044DC-B39400DB-D8EF3FFA Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe Abley wrote: > I have been trying to make the definitions as solution-neutral > as possible. This may not be possible because all the terms are already so overloaded in different contexts. :) > The word "enterprise" is only really being used to describe an > entity which is able to multi-home. So the guy next door with ADSL and Cable modem is an enterprise? I think the problem is assuming that there is any association between the size of an attaching entity and the routing policies it will try to inflict. Even if current operational experience shows a correlation between size and a particular activity; five years from now the words used to describe the activity will be the same but the size will be smaller, so the entity being described by those words will be different. > On the other hand, if you have a better definition, let's > hear it. I have been trying to understand what the intent of the distinctions is. If the scope is limited to the example of an entity attaching to two (or more) providers and having the traffic flow over those attachment points without traversing another provider, then your current evolved definition is sufficient. If the intent is to eventually describe a variety of routing policies expressions beyond the attached providers of the entity, then directionality becomes a problem. B might want to punch a policy through C to E to influence a mutual customer of D & E, even though the 'global Internet' is upstream through A. Does this make C a 'transit provider' for B or E, or a 'transit network', or all of the above? If the definition requires directionality toward A then does it become none of the above? If C acquires its address space from B does this change anything? Tony From owner-multi6@ops.ietf.org Fri Jun 29 21:32:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29586 for ; Fri, 29 Jun 2001 21:32:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G8sT-000GmY-00 for multi6-data@psg.com; Fri, 29 Jun 2001 17:44:49 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.30 #1) id 15G8sR-000GmM-00 for multi6@ops.ietf.org; Fri, 29 Jun 2001 17:44:48 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 29 Jun 2001 13:40:08 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id C096AFC5EFCE4BD8BB4DAB6C7240AFCE for plus 4 more; Fri, 29 Jun 2001 13:40:08 -0700 Reply-To: From: "Tony Hain" To: "Joe Abley" , "Tony Hain" Cc: "Randy Bush" , "Ben Black" , Subject: RE: requirements draft revision Date: Fri, 29 Jun 2001 13:36:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010629153421.H3425@buddha.home.automagic.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: CDE9835B-35E64C94-9E80D32A-DAA39C0E Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe Abley wrote: > > > An "enterprise" is an entity autonomously operating a > > > network using TCP/IP and, in particular, determining the > > > addressing plan and address assignments within that network. > > > ... snip ... > Yes. If a customer of C can reach the rest of the internet through C, > then C is a transit provider of that customer. Here's the updated > diagram: > > A --- B --- C --- F > | | > D E > > F is the customer of C. > > > > What is the difference between that and > > using a dial-in NAT to map 10/8 through a single address received > from C? > > I don't understand the question. It's the fact that C is > providing connectivity to the internet beyond C that makes it > a transit provider. I don't understand what addressing and/or > the presence of NAT has to do with it in the general case. > > > They both fit the definition of Enterprise here. > > Yes. A, B, C, D, E and F are all enterprises, according to > what I meant to convey in the text. If we can make things > clearer by introducing a new term for "an enterprise which > has a transit provider", as Randy seemed to be saying, then > that's cool. We can do that. > > > In both cases the address > > space and routing policies presented to B & E belong to C, so what > makes C a > > 'transit' provider? > > The fact that C provides internet connectivity for F. The reason I have been hammering on this is there are some underlying assumptions everyone has about what these terms mean, and buried in those assumptions are mechanisms for what needs to happen to make things work. The reason for the NAT question was trying to distinguish the difference between an individual dialing in vs. a larger organization. Basically, what does F managing address space have to do with the discussion of C being a transit or not? Does any collection of routed subnets constitute an 'Enterprise'? If so do we care about all of them, or only the ones that are trying to punch a policy through C? Is there a way to distinguish those cases? The fundamental point I was getting to with that last set of questions was trying to really nail the definition of 'transit'. The last line of your response implies single directionality. Why is C not a transit provider of B? (hint: the term 'customer' may not appear in the answer) If the Internet were a single rooted tree the single directionality definition would work, but the Internet is a mesh, so the definition is a mess. Are you really trying to identify a term for the set of transit networks where one of the attached parties is a stub? Tony From owner-multi6@ops.ietf.org Fri Jun 29 21:56:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00694 for ; Fri, 29 Jun 2001 21:56:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G9fQ-000IJx-00 for multi6-data@psg.com; Fri, 29 Jun 2001 18:35:24 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.30 #1) id 15G9fP-000IJf-00; Fri, 29 Jun 2001 18:35:23 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id UAA24671; Fri, 29 Jun 2001 20:35:31 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Fri, 29 Jun 2001 20:35:31 -0500 (CDT) From: "Jon (Taz) Mischo" To: Joe Abley cc: Tony Hain , Randy Bush , Ben Black , multi6@ops.ietf.org Subject: Re: requirements draft revision In-Reply-To: <20010629211653.M26708@buddha.home.automagic.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 29 Jun 2001, Joe Abley wrote: > > No, it's the fact that C will route _any_ of its customers' traffic to > > We were avoiding the use of "customer", I think, in the interests of finding > a technical description as opposed to a commercial one. A transit provider can ONLY be described by its relationship to a customer, as it is a term used to describe a commercial behavior. > > either its destination or to an egress point nearer (usually) its > > destination that makes it a transit provider. The word any is the key. A > > peer will route any traffic you send it that is destined for its own > > network, and sometimes to other agreed upon networks. A transit provider > > routes you to EVERYTHING. > > Right. Isn't this encapsulated in Randy's use of "global"? Yes, I believe so. I was just arguing with the latest round of descriptions, because Randy's point seemed to have bounced off. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Sat Jun 30 01:16:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04939 for ; Sat, 30 Jun 2001 01:16:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GD7F-0003Id-00 for multi6-data@psg.com; Fri, 29 Jun 2001 22:16:21 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.30 #1) id 15GD7E-0003IX-00; Fri, 29 Jun 2001 22:16:20 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id AAA24888; Sat, 30 Jun 2001 00:15:24 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Sat, 30 Jun 2001 00:15:24 -0500 (CDT) From: "Jon (Taz) Mischo" To: Tony Hain cc: Joe Abley , Randy Bush , Ben Black , multi6@ops.ietf.org Subject: RE: requirements draft revision In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 29 Jun 2001, Tony Hain wrote: > Jon (Taz) Mischo wrote: > > > A transit provider can ONLY be described by its relationship to a > > customer, as it is a term used to describe a commercial behavior. > > No, transit is a technical function of bit delivery. There is no customer > relationship implied or required. No, TRANSPORT is a technical function, transit is a service. You transport a package across state lines, you don't transit it. Same goes for packets. You do, however, use public transit (a pay service) to transport you places in most big cities. See the difference? -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Sat Jun 30 05:23:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20651 for ; Sat, 30 Jun 2001 05:23:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GGYS-000E0S-00 for multi6-data@psg.com; Sat, 30 Jun 2001 01:56:40 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.30 #1) id 15GGYQ-000E0M-00 for multi6@ops.ietf.org; Sat, 30 Jun 2001 01:56:39 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 29 Jun 2001 21:52:50 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 85AC3C4CD8C34C978124D405B1F4286D for plus 5 more; Fri, 29 Jun 2001 21:52:50 -0700 Reply-To: From: "Tony Hain" To: "Jon \(Taz\) Mischo" , "Joe Abley" Cc: "Tony Hain" , "Randy Bush" , "Ben Black" , Subject: RE: requirements draft revision Date: Fri, 29 Jun 2001 21:48:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: FC2D7F55-4CBB4E8B-ABC7B360-870A5577 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jon (Taz) Mischo wrote: > A transit provider can ONLY be described by its relationship to a > customer, as it is a term used to describe a commercial behavior. No, transit is a technical function of bit delivery. There is no customer relationship implied or required. Tony From owner-multi6@ops.ietf.org Sat Jun 30 07:09:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21136 for ; Sat, 30 Jun 2001 07:09:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GIK1-000J8f-00 for multi6-data@psg.com; Sat, 30 Jun 2001 03:49:53 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.30 #1) id 15GIK0-000J8U-00 for multi6@ops.ietf.org; Sat, 30 Jun 2001 03:49:52 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f5UAoaH11764; Sat, 30 Jun 2001 12:50:37 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 30 Jun 2001 12:49:58 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Joe Abley cc: multi6@ops.ietf.org Subject: Re: requirements draft revision In-Reply-To: <20010629145433.A3425@buddha.home.automagic.org> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 29 Jun 2001, Joe Abley wrote: > A --- B --- C > | | > D E > A, B, C, D are all enterprises. B, E are transit providers of C. > A, D are transit providers of B. Both C and B are multi-homed. I don't like the implied definition of multihomed. I think it should be something along the lines of: An enterprise or network is multihomed if it connects to two or more transit providers and is not a transit provider itself. Today there is no real distinction between just being multihomed and also providing transit services, but in a new system the two may be very different. Connecting to just a few peers is doesn't qualify as being multihomed in my book because the routing information doesn't reach the default free zone. Iljitsch From owner-multi6@ops.ietf.org Sat Jun 30 15:44:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25035 for ; Sat, 30 Jun 2001 15:44:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GQA6-000EE4-00 for multi6-data@psg.com; Sat, 30 Jun 2001 12:12:10 -0700 Received: from flowpoint.procket.com ([209.140.237.1] helo=alpha-tli.procket.com) by psg.com with esmtp (Exim 3.30 #1) id 15GQA4-000ECZ-00; Sat, 30 Jun 2001 12:12:08 -0700 Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id MAA04001; Sat, 30 Jun 2001 12:11:23 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15166.9307.556182.633818@alpha-tli.procket.com> Date: Sat, 30 Jun 2001 12:11:23 -0700 To: Joe Abley Cc: Tony Hain , Randy Bush , Ben Black , multi6@ops.ietf.org Subject: Re: requirements draft revision In-Reply-To: <20010629171052.A26708@buddha.home.automagic.org> References: <20010629153421.H3425@buddha.home.automagic.org> <20010629171052.A26708@buddha.home.automagic.org> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | On the other hand, if you have a better definition, let's hear it. Randy sent you a fine definition that matches common accepted usage of the term. Using that would be easier than trying to get the rest of the industry to change their definition. Tony