Subject: Re: [Hipsec] Feedback for 4423bis

From: Miika Komu <[email-masked]>
Date: Fri, 08 Nov 2013 08:45:22 +0200

Hi,

On 10/25/2012 09:09 PM, Miika Komu wrote:
> Hi,
>
> On 10/21/2012 06:21 PM, Miika Komu wrote:
>> Hi,
>>
>> On 10/19/2012 12:38 AM, Miika Komu wrote:
>>> Hi,
>>>
>>> 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.
>>>
>>> looks good to me too but I have also some suggestions for improvement.
>>> Here's the first batch of comments, I'll send the remaining ones later.
>>
>> the second batch is here, I'll send the third and final later.
>
> the third and final batch is now here. Sorry for the delay.

I fixed my own suggestions in the new version since there were no 
objections.

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

---

From: Miika Komu <[email-masked]>
Date: Fri, 08 Nov 2013 08:58:38 +0200

Hi Sasu,

> very good. Below you will find some observations that I made

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.