[Hipsec] fault-tolerance for base exchange and update
Miika Komu <miika.komu@hiit.fi> Thu, 07 January 2010 07:20 UTC
Return-Path: <miika.komu@hiit.fi>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7073F3A635F for <hipsec@core3.amsl.com>; Wed, 6 Jan 2010 23:20:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.358
X-Spam-Level:
X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oo1SLZcK+6P0 for <hipsec@core3.amsl.com>; Wed, 6 Jan 2010 23:20:42 -0800 (PST)
Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id C282B3A6983 for <hipsec@ietf.org>; Wed, 6 Jan 2010 23:20:41 -0800 (PST)
Received: from [192.168.0.2] (cs27096138.pp.htv.fi [89.27.96.138]) by argo.otaverkko.fi (Postfix) with ESMTP id 0F07925ED1A; Thu, 7 Jan 2010 09:20:40 +0200 (EET)
Message-ID: <4B458BB7.8090000@hiit.fi>
Date: Thu, 07 Jan 2010 09:22:31 +0200
From: Miika Komu <miika.komu@hiit.fi>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: hip WG <hipsec@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [Hipsec] fault-tolerance for base exchange and update
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: miika.komu@hiit.fi
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2010 07:20:50 -0000
Hi, Baris Boyvat has implemented an experimental fault-tolerance extension for the HIP base exchange and UPDATE in the HIPL implementation. He will document it in his master thesis during this year, but I would like to start discussion of the topic already now. At the protocol level, the extension allows sending multiple I1 or UPDATE-with-locator packets sequentially. The idea is to scan through all possible source and destination IP pairs at the HIP layer to improve the chances for successful initial contact (I1) and to re-establish contact (UPDATE-with-locator) in way similar to the NAT-ICE extensions. We have playfully called the extension as "shotgun" mode in the implementation :) The obvious difference to ICE is that the shotgun mode works at the HIP protocol layer. A non-obvious difference is that the approach supports also fault-tolerance for a single relay/rendezvous (Responder's RVS has crashed) and it can make use of multiple relay/rendezvous servers for better redundancy. At the moment, neither of these are possible direcly with the ICE-NAT extensions. I actually believe the shotgun approach can be applied even with the ICE-NAT extensions to improve fault-tolerance. The shotgun approach seems useful to improve fault-tolerance with an without (single or multiple) rendezvous/relay middleboxes, but there is also another use case for this. The Initiator (or Mobile Node) can learn multiple mappings for the peer, some of which may have connectivity and some not. It is also possible that a malign user intentionally sends invalid mappings for a well-known service in a multiuser system (this case also requires some rate control for mappings per user). In such scenarios, it is useful to try multiple peer addresses sequentially instead of just single one. Minimally, the approach requires few considerations in an implementation: i) Allow sending of multiple I1 and UPDATE-with-locator packets in a rate-controlled fashion ii) Filter redundant incoming packets. Case (ii) could be implemented as filtering of I1 packets or filtering of R1 packets. We chose filtering of redundant R1 packets in the implementation and it required a small change in the state machine. For the UPDATE filtering, filtering based on sequence numbers was sufficient. I would like the WG feedback on whether we could include this approach in RFC5201-bis and RFC5206-bis (as MAY or SHOULD). P.S. Maybe Baris has something to add or to explain some details better.
- [Hipsec] fault-tolerance for base exchange and up… Miika Komu
- Re: [Hipsec] fault-tolerance for base exchange an… Andrew McGregor
- Re: [Hipsec] fault-tolerance for base exchange an… Tobias Heer
- Re: [Hipsec] fault-tolerance for base exchange an… Miika Komu
- Re: [Hipsec] fault-tolerance for base exchange an… Laganier, Julien
- Re: [Hipsec] fault-tolerance for base exchange an… Miika Komu