Re: [hiprg] HIP experiment report comment on opportunistic mode

Miika Komu <> Tue, 06 December 2011 15:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F42021F8669 for <>; Tue, 6 Dec 2011 07:08:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IpUIflE53Pr0 for <>; Tue, 6 Dec 2011 07:08:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5603F21F85F2 for <>; Tue, 6 Dec 2011 07:08:47 -0800 (PST)
Received: from ([] helo=[]) by with esmtp (Exim 4.54) id 1RXwdQ-0004Ox-JI for; Tue, 06 Dec 2011 17:08:45 +0200
Message-ID: <>
Date: Tue, 06 Dec 2011 17:08:41 +0200
From: Miika Komu <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: "" <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [hiprg] HIP experiment report comment on opportunistic mode
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Dec 2011 15:08:48 -0000


On 12/06/2011 10:21 AM, Tobias Heer wrote:
> Hi,
> Am 06.12.2011 um 09:01 schrieb Henderson, Thomas R:
>> I would like to respond to one of Stephen Farrell's comment on the
>> HIP experiment report:
>> The comment is:
>> " - I wondered what were the "controversial experiences" on p10.
>> Seems a shame to tease the reader like that."
>> The relevant section of text is:
>> In the context of the HIPL project, the opportunistic mode has
>> been successfully applied at the HIP layer for service
>> registration [RFC5203].  However, there are controversial
>> experiences on applying opportunistic mode at the application layer
>> for legacy software. HIP4BSD implemented opportunistic mode
>> successfully with small modifications to the FreeBSD socket layer
>> to support opportunistic mode.
>> Could someone elaborate on the controversial experience (and
>> perhaps provide a reference)?  Note that elsewhere in the report
>> (section 2.3.2), the disadvantages and "leap of faith" aspects of
>> opportunistic mode are elaborated on, so I'm wondering whether the
>> reference to controversial experiences goes beyond the
>> disadvantages already listed in section 2.3.2 (or whether we could
>> instead strike those words from the draft and refer back to that
>> section).
> As far as I can tell, we in Aachen have not used the opportunistic
> mode extensively. Miika seemed to have used it/struggled with it
> quite a bit. Maybe he has some comments on this.

we implemented opportunistic HIP mode at two different levels in Linux:

i. As an intercepting SHIM library between the application and the libc 
socket calls implementations using LD_PRELOAD
ii. As an intercepting SHIM layer between transport and network layers 
using iptables

While the implementation was a success, it was not far from ready for 
production use and we decided to remove the data plane part from the 
implementation. However, the control planet part (opportunistic base 
exchange) is still left and can be used e.g. for registering for rendezvous.

So I guess the "controversial" means perhaps that the data plane 
processing was more difficult to implement on Linux than on BSD, I 
suggest rewriting something along these lines or just referencing the 
paper for details (you have the reference already in the draft).

Btw, I would appreciate if you could reference also the following paper 
in the report:

Kristiina Karvonen, Miika Komu and Andrei Gurtov, Usable Security 
Management with Host Identity Protocol, published in The 7th ACS/IEEE 
International Conference on Computer Systems and Applications (AICCSA-2009)

It supplements opportunistic and normal HIP experiments with usability 
test results. We also report experiences from using a graphical end-host 
firewall. I would kindly ask a reference, e.g., to section 2.3.2:

"...or by prompting the user using a graphical interface to explicitly 
accept the connection [REF]."