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
- [Hipsec] Feedback for 4423bis Sasu Tarkoma
- Re: [Hipsec] Feedback for 4423bis Miika Komu
- Re: [Hipsec] Feedback for 4423bis Robert Moskowitz
- Re: [Hipsec] Feedback for 4423bis Miika Komu
- Re: [Hipsec] Feedback for 4423bis Miika Komu
- Re: [Hipsec] Feedback for 4423bis Miika Komu
- Re: [Hipsec] Feedback for 4423bis Miika Komu
- Re: [Hipsec] Feedback for 4423bis Miika Komu