[hiprg] Tentative review of HIP DEX draft

Peter Nick <peternick132000@yahoo.com.cn> Mon, 17 January 2011 13:51 UTC

Return-Path: <peternick132000@yahoo.com.cn>
X-Original-To: hiprg@core3.amsl.com
Delivered-To: hiprg@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id EC08B3A6F37 for <hiprg@core3.amsl.com>; Mon, 17 Jan 2011 05:51:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id pqUPo7ez7ix9 for <hiprg@core3.amsl.com>; Mon, 17 Jan 2011 05:51:31 -0800 (PST)
Received: from n3b.bullet.cnb.yahoo.com (n3b.bullet.cnb.yahoo.com []) by core3.amsl.com (Postfix) with SMTP id 00E963A6CAA for <hiprg@irtf.org>; Mon, 17 Jan 2011 05:51:30 -0800 (PST)
Received: from [] by n3.bullet.cnb.yahoo.com with NNFMP; 17 Jan 2011 13:54:01 -0000
Received: from [] by t2.bullet.cnb.yahoo.com with NNFMP; 17 Jan 2011 13:54:01 -0000
Received: from [] by omp106.mail.cnb.yahoo.com with NNFMP; 17 Jan 2011 13:54:01 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 702957.95268.bm@omp106.mail.cnb.yahoo.com
Received: (qmail 11360 invoked by uid 60001); 17 Jan 2011 13:54:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1295272441; bh=sSy0XOZpEUdY9acHov1gEVxarhVgdzABEJdR6y1EBiI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=botgp8BxTfxQaB4jn4dMhrbK9M/KocwUJXfgo9OoYgvlJC4MQu33H1SgeBLAlRsptszWw47S13mc7ei2TIzlbCGVp+v9/ZiKkGf8i2GBGgBvQIu3+M8kYPgcC4X61EhMyZ+k1jJCuxtJ1hhPe7j3zQnmRwee/YGnk0Ne5mg81qI=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=inOE2nQViwKaHmgV2enZsECp+Saxob+P2YVjzlhDhC++RKxFpuQhph5N3bi/QWn0QFtBfYwXQSgZhTY7J3vkiNoM9mccKHJv7wWcUfa5ABl92wRshgV5T0Xm8hQB93ugnN+ifaApI5lph22Ux4fyedHojGRivD1oQmQpVgmlyDs=;
Message-ID: <586494.11195.qm@web15803.mail.cnb.yahoo.com>
X-YMail-OSG: EgkgcGMVM1m9mRQ0NemHANJltP70YtQf7o4oRQk_yaagtTW p9TSPwBjDMB3IF25GXn4DdFdGlH.qdMprXa3.UGe5.qnqBv7Of3qIcMrfHOx 7.JLYNDMg2QANMpbf2bsWDC17sgQmgowgs4fOwU1O9f38xv7YRk7QCDpZqeR kNwO66heoSLIp6U.S_d0HSxFWsLM4WZD6KOwqT8Yp0weV2OBwS7daq5KrmjY kpY4TMNMkEVF.Whj1ZKG9BrZ4.AFbPhNC1g.X4WJD5Q--
Received: from [] by web15803.mail.cnb.yahoo.com via HTTP; Mon, 17 Jan 2011 21:54:01 CST
X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/
Date: Mon, 17 Jan 2011 21:54:01 +0800 (CST)
From: Peter Nick <peternick132000@yahoo.com.cn>
To: hiprg@irtf.org, robert.moskowitz@icsalabs.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1714191536-1295272441=:11195"
Subject: [hiprg] Tentative review of HIP DEX draft
X-BeenThere: hiprg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <hiprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/hiprg>
List-Post: <mailto:hiprg@irtf.org>
List-Help: <mailto:hiprg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jan 2011 13:51:35 -0000

Hi, dear Mr.Robert,
This is Nie Pin, a researcher who is working on security solutions for Wireless Sensor Network (WSN). My colleague Miika Komu and Prof.Andrei Gurtov suggested me to investigate possibility to adopt Diet HIP.
I read your IETF draft "HIP Diet EXchange (DEX)" --- draft-moskowitz-hip-rg-dex-02, and have a few comments and questions as below:
1. Page 1, Abstract 2nd paragraph says "... sensor devices that are code and processor constrained...", I suggest to replace "code" with "memory", which is more precise in WSN research domain. 
2. Page 4, Introduction, 7th paragraph says "Static/Static Elliptic Curve...". Guess one "Static" should be removed.
3. Page 6, Section 3.1 HIT says "The DEX Host Identity Tag is a 128-bit value -- a truncation of the Host Identifier...". But in the page 7, 2nd paragraph says "In DEX, ... Rather the HI is truncated to 96 bits." It is confusing how a 128-bit DEX HIT is longer than 96-bit HI?
4. Page 8, 1st paragraph, the last sentence says "The packet is MACed by the sender...", is MAC here short for Message Authentication Code? If so, I wonder if "hashed with MAC" could be more precise?
5. Page 10, Section HIP Aggresive Transmission Mechanism. The "Aggresive" is mis-spelled, should be "Aggressive". In the 1st paragraph, it says "The initiator SHOULD continually send I1 and I2 packets at some short interval t msec, based on local policy." It is a bit ambiguous about " local policy". In WSN, I think the delay is mainly driven by Round-trip-time (RTT). Local computing overhead of puzzle should be trivial in terms of latency. Otherwise, K value may be too big, implying high difficulty and significant energy consumption.
6. Page 14, Section  Pair-wise Key SA, 3rd paragraph, 3rd sentence has an extra "is". "... this input is is randomly distributed,..."
7. Page 15, Section 5.1 HIP parameters. Since parameters are encoded in TLV, I don't know why the table uses "Data" as the name of the 4th column. "Value" is clearer to understand the abbreviation TLV. The content in the 4th cell of the 2nd row misused two conjunction words "Encrypted container of for key generation..."
8. Page 15, Section 5.1.1. HIT_SUITE_LIST, the HIT suites in DEX has no ID for ECDSA/DEX, but only for ECDH/DEX, ID 8. If ECDSA/DEX is employed, what ID number should I give?
9. Page 18, 2nd paragraph says "The HIP packet, however MUST NOT be fragmented." This is impossible to achieve in IEEE 802.15.4, because the maximum payload is 102 bytes in a MAC frame after headers (RFC 4944, Section 4). While, the minimum size of I2, R1 and R2 already exceeds this limit. Therefore, packet fragmentation is inevitable at the network layer.
10. Page 18, the last sentence at the bottom "Implementations MUST be able to handle a storm of received I1". It is impossible and also unnecessary to build this feature. A storm of I1 indicates DOS attack considering the average simultaneous link channels (<= 8 typically in TDMA) in most of WSN applications. Moreover, due to the memory constraint, the packet buffer on a sensor node is quite limited. Security cannot take a big share of it and causes significant overhead. Otherwise, it is infeasible to employ on WSN in consideration of lifetime and information throughput.
11. Page 29, two mis-spelling in the 1st paragraph "... configured with a  authentication password..." --> "... configured with an  authentication password..."; "... it constructs the autentication response..." --> "... it constructs the authentication response..."
12. Do you have any beta implementation work or micro benchmarking of HIP DEX? And micro benchmarking papers on HIP BEX. I'm interested in its performance and overhead analysis.

Thanks for your consideration and effort :)