IETF Logo Mail Archive

Re: Renumbering ... Should we consider an association that spans transports?

Karl Auerbach <karl@cavebear.com> Thu, 13 September 2007 21:00 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVvnx-0005VD-P0; Thu, 13 Sep 2007 17:00:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVvnw-0005V8-LI for ietf@ietf.org; Thu, 13 Sep 2007 17:00:52 -0400
Received: from lear.cavebear.com ([64.62.206.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVvnv-0007WT-Bb for ietf@ietf.org; Thu, 13 Sep 2007 17:00:52 -0400
Received: from [192.168.225.175] (dsl-63-249-107-235.cruzio.com [63.249.107.235]) (authenticated bits=0) by lear.cavebear.com (8.13.7/8.13.4) with ESMTP id l8DL0nSd015033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Sep 2007 14:00:50 -0700
Message-ID: <46E9A501.5040500@cavebear.com>
Date: Thu, 13 Sep 2007 14:00:49 -0700
From: Karl Auerbach <karl@cavebear.com>
User-Agent: Thunderbird 1.5.0.12 (X11/20070719)
MIME-Version: 1.0
To: David Conrad <drc@virtualized.org>
References: <200709130810.l8D8A4mN067629@drugs.dv.isc.org> <46E92188.5070504@iglou.com> <2990.1189685347.711941@peirce.dave.cridland.net> <2098B1AA-19B6-4F99-BB7C-6A7631AFC628@virtualized.org> <Pine.LNX.4.64.0709131942470.22434@hermes-2.csi.cam.ac.uk> <823FD693-9B95-4602-8F49-6A4D7E7337CF@virtualized.org>
In-Reply-To: <823FD693-9B95-4602-8F49-6A4D7E7337CF@virtualized.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: IETF-Discussion <ietf@ietf.org>
Subject: Re: Renumbering ... Should we consider an association that spans transports?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

David Conrad wrote:

>>> How do you renumber the IP address stored in the struct sockaddr_in in a
>>> long running critical application?
...
> If you had a separation between locator and identifier, the application 
> could bind to the identifier and renumbering events could occur on the 
> locators without impacting the identifier.

For a long time I've suggested that we begin to look anew at the idea of 
an "association" as an abstraction over "transport".  Yes, I know that 
this smacks if ISO/OSI, but there were a few granules of good ideas there.

The idea is this:  An "association" is an end-to-end relationship 
between a pair of applications that potentially spans several transport 
lifetimes.

Then, if the underlying transport goes away, perhaps due to movement in 
a mobile network or renumbering, then the association is reconstructed 
on a new transport that is built in accord with the current addressing 
and routing conditions.

Reconstruction does not, as some have assumed, require that the network 
remember anything or hold any state.  Rather, taking a cue from ISO/OSI, 
the trick is that the association layer is merely a means for the 
applications to reliably exchange checkpoint names.  What those 
checkpoint names mean is up to the applications - thus what to do if a 
rebinding to a new transport requires going back to a checkpoint is 
something entirely within the application and its networking library 
code, not some state that is stored in the net.

Basically whenever applications establish a transport they say "Ahem, 
where were we when we last spoke".  One answer is "We did not last 
speak"  Another answer is "we last agreed on the checkpoint named 
'foo'".  How they recover from 'foo' is entirely application dependent.

(I have not really considered the security implications - in the absence 
of some form of shared secret or other authentication on association 
re-establishment there would probably be a race condition in which an 
intruder could jump in.)

(I'm also thinking of TCP based applications, not UDP based ones.  For 
them I don't see renumbering as much of a problem, but I may not be 
seeing enough.)

This is not something that can readily be transparently back-ported into 
existing protocols; it's not something of trivial import.  But it can be 
deployed for new applications and not invalidate either existing 
applications or existing application protocols.

And consider, for example, how something like this might have obviated 
the need for the IP layer triangulation in mobile IP.

		--karl--

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

v2.23.0 | Report a Bug | By Email