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
- [RAM] Renumbering impossibility: TSL/SSL certs, D… Robin Whittle
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Thomas Narten
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Gert Doering
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Stig Venaas
- [RAM] Re: Renumbering impossibility: TSL/SSL cert… Stephane Bortzmeyer
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Robin Whittle
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Olivier Bonaventure
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Robin Whittle
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Gert Doering
- [RAM] "End-users" & things I think warrant more a… Robin Whittle
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… JFC Morfin
- [RAM] Re: Renumbering impossibility: TSL/SSL cert… Stephane Bortzmeyer
- [RAM] Re: Renumbering impossibility: TSL/SSL cert… Stephane Bortzmeyer
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … Gert Doering
- [RAM] Re: Renumbering impossibility: TSL/SSL cert… Gert Doering
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … JFC Morfin
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … Thomas Narten
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … Gert Doering
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … JFC Morfin
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … JFC Morfin
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … Roland Dobbins
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … JFC Morfin
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Jari Arkko