Re: [Hipsec] Feedback for 4423bis

Miika Komu <mkomu@cs.hut.fi> Fri, 08 November 2013 06:58 UTC

Return-Path: <mkomu@cs.hut.fi>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DDE21E80E0 for <hipsec@ietfa.amsl.com>; Thu, 7 Nov 2013 22:58:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBsboQcpTi7h for <hipsec@ietfa.amsl.com>; Thu, 7 Nov 2013 22:58:45 -0800 (PST)
Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id B730721E80A8 for <hipsec@ietf.org>; Thu, 7 Nov 2013 22:58:40 -0800 (PST)
Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 84F9C3081BA for <hipsec@ietf.org>; Fri, 8 Nov 2013 08:58:38 +0200 (EET)
Message-ID: <527C8B9E.4090404@cs.hut.fi>
Date: Fri, 08 Nov 2013 08:58:38 +0200
From: Miika Komu <mkomu@cs.hut.fi>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: hipsec@ietf.org
References: <502A164E-8CCA-459B-A404-4E668150A684@helsinki.fi>
In-Reply-To: <502A164E-8CCA-459B-A404-4E668150A684@helsinki.fi>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Hipsec] Feedback for 4423bis
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 08 Nov 2013 06:58:50 -0000

Hi Sasu,

On 10/10/2012 10:05 PM, Sasu Tarkoma wrote:
> Hi all,
>
> I read the latest HIP architecture draft (4423bis-05) and it looks
> very good. Below you will find some observations that I made
> when reading the draft.

thanks for the comments!

> - Architecture and implementation details are partly
>   intertwined here. Perhaps the generic model can
> be summarised first and then the implementation
> specific details. Theory of HI is mentioned in the
> beginning, but I think it is not clear for all readers what
> is meant by this.
>
> - It is stated that the model is general and it does not require
> public key crypto; however, this is not really elaborated. Also
> it is stated that the model can be applied at any
> layer, but this is not explained. The description assumes
> that Host Identity decouples internetworking and
> transport layers.

I have tried to improve the text in general.

> - The draft does not discuss architecture and protocol
> deployment issues. This is one practical requirement given
> the momentum of the current solutions.

Done.

> - The description of the HIP protocol is quite light in this
> draft. The introductory part to section 5 could briefly state the
> key components of HIP including BEX, mobility/multihoming support,
> and rendezvous that are covered by the following subsections.

Done.

> - In section 5, it is stated that:
> "Similarly, if it is possible to distribute the processing of a single
>     Host Identity over several physical computers, HIP provides for
>     cluster based services without any changes at the client end-point."
>
> I think the base specification and implementation do not directly
> support this, but additional management extensions are needed.

Agreed, I have modified the text.

> - Computational puzzle does not appear to be mentioned.

Now they are.

> - Extensions (new hash functions) are not elaborated. This is
> related to a general requirement that a protocol should be evolvable.
>
> - p. 17 section 10 needs a reference
>
> - p. 21 the downgrade attack should be elaborated.
>
> - Typo: p. 5 Identfier

Fixed.

The new version includes a number of references, including peer-reviewed 
papers and a few citations to the most relevant work-in-progress drafts 
(I hope citing drafts is ok). The ideas did not arrive from thin air, so 
I felt compelled to cite the original work and point out an interested 
reader to the right direction for more details.

http://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis-06