Re: [RAM] Renumbering impossibility: TSL/SSL certs, DNS delegation etc.

Jari Arkko <jari.arkko@piuha.net> Wed, 22 August 2007 15:39 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INsIg-0005Ll-PJ; Wed, 22 Aug 2007 11:39:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INsIe-0005La-Om for ram@iab.org; Wed, 22 Aug 2007 11:39:16 -0400
Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INsId-0006P8-Dh for ram@iab.org; Wed, 22 Aug 2007 11:39:16 -0400
Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A80F51986A6; Wed, 22 Aug 2007 18:39:14 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5BF03198680; Wed, 22 Aug 2007 18:39:14 +0300 (EEST)
Message-ID: <46CC58A2.6000309@piuha.net>
Date: Wed, 22 Aug 2007 18:39:14 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: Robin Whittle <rw@firstpr.com.au>
Subject: Re: [RAM] Renumbering impossibility: TSL/SSL certs, DNS delegation etc.
References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au>
In-Reply-To: <46B8971C.3020008@firstpr.com.au>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: ram@iab.org
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

Robin,

I'm in catchup e-mail mode...

> Also, they would be running links to other offices, which would all
> need to be broken and re-established on new IP addresses if
> multihoming meant getting new addresses.
>   

Just FYI...

IPsec VPNs are are capable of surviving address changes when
they are using either NAT traversal or IKE multihoming extensions
(RFC 4555).

> What about SSHing from outside into a server in the network?  It
> would be not such a good thing to find the server suddenly on
> another IP address from last time, due to a multihoming service
> restoration operation.  I assume SSH would be fussy about that, but
> perhaps I am wrong about that too.

SSH could also be made resilient to address changes:

 
http://www.usenix.org/events/usenix06/tech/full_papers/koponen/koponen_html/index.html

This isn't used anywhere right now AFAIK and deals with the
client side movements rather than the server. In any case...

> Having the whole network suddenly adopt new addresses due to some
> multihoming service restoration event sounds like 100% trouble and
> 0% convenience and elegance.  It would be far better to have
> portable IP addresses which remained the same no matter what
> happened with multihoming.
>   

Sure -- I'm not advocating a model where all these things have to be
taken into account by the individual protocols such as the ones
above. However, given the state of the world right now, people
have found ways to get many of their applications working
despite IP address changes. Routing around damage, you
might say...

Jari


_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram