From peternick132000@yahoo.com.cn Mon Jan 17 05:51:34 2011 Return-Path: X-Original-To: hiprg@core3.amsl.com Delivered-To: hiprg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC08B3A6F37 for ; 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-Level: 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqUPo7ez7ix9 for ; Mon, 17 Jan 2011 05:51:31 -0800 (PST) Received: from n3b.bullet.cnb.yahoo.com (n3b.bullet.cnb.yahoo.com [202.43.216.213]) by core3.amsl.com (Postfix) with SMTP id 00E963A6CAA for ; Mon, 17 Jan 2011 05:51:30 -0800 (PST) Received: from [202.43.217.102] by n3.bullet.cnb.yahoo.com with NNFMP; 17 Jan 2011 13:54:01 -0000 Received: from [203.209.230.77] by t2.bullet.cnb.yahoo.com with NNFMP; 17 Jan 2011 13:54:01 -0000 Received: from [127.0.0.1] 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 [62.237.152.76] by web15803.mail.cnb.yahoo.com via HTTP; Mon, 17 Jan 2011 21:54:01 CST X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Mon, 17 Jan 2011 21:54:01 +0800 (CST) From: Peter Nick 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 13:51:35 -0000 --0-1714191536-1295272441=:11195 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi, dear Mr.Robert, This is Nie Pin, a researcher who is working on security solutions for Wire= less Sensor Network (WSN). My colleague Miika Komu and Prof.Andrei Gurtov s= uggested 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 an= d processor constrained...", I suggest to replace "code" with "memory", whi= ch is more precise in WSN research domain.=20 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 val= ue -- a truncation of the Host Identifier...". But in the page 7, 2nd parag= raph says "In DEX, ... Rather the HI is truncated to 96 bits." It is confus= ing 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 th= e sender...", is MAC here short for Message Authentication Code? If so, I w= onder if "hashed with MAC" could be more precise? 5. Page 10, Section 4.1.3.1 HIP Aggresive Transmission Mechanism. The "Aggr= esive" is mis-spelled, should be "Aggressive". In the 1st paragraph, it say= s "The initiator SHOULD continually send I1 and I2 packets at some short in= terval 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 significa= nt energy consumption. 6. Page 14, Section 4.1.4.2.=A0 Pair-wise Key SA, 3rd paragraph, 3rd senten= ce 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. "Va= lue" is clearer to understand the abbreviation TLV. The content in the 4th = cell of the 2nd row misused two conjunction words "Encrypted container of f= or 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 fragmen= ted." This is impossible to achieve in IEEE 802.15.4, because the maximum p= ayload is 102 bytes in a MAC frame after headers (RFC 4944, Section 4). Whi= le, 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 ave= rage simultaneous link channels (<=3D 8 typically in TDMA) in most of WSN a= pplications. 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 c= auses 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= =A0 authentication password..." --> "... configured with an=A0 authenticati= on password..."; "... it constructs the autentication response..." --> "...= it constructs the authentication response..." 12. Do you have any beta implementation work or micro benchmarking of HIP D= EX? And micro benchmarking papers on HIP BEX. I'm interested in its perform= ance and overhead analysis. Thanks for your consideration and effort :) BR niepin =0A=0A=0A --0-1714191536-1295272441=:11195 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, dear Mr.Robert,
This is Nie Pin, a res= earcher who is working on security solutions for Wireless Sensor Network (W= SN). My colleague Miika Komu and Prof.Andrei Gurtov suggested me to investi= gate possibility to adopt Diet HIP.
I read your IETF draft "HIP Diet EXc= hange (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. P= age 4, Introduction, 7th paragraph says "Static/Static Elliptic Curve...". = Guess one "Static" should be removed.
3. Page 6, Section 3.1 HIT says "T= he DEX Host Identity Tag is a 128-bit value -- a truncation of the Host Ide= ntifier...". 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 pa= cket is MACed by the sender...", is MAC here short for Message Authenticati= on Code? If so, I wonder if "hashed with MAC" could be more precise?
5. = Page 10, Section 4.1.3.1 HIP Aggresive Transmission Mechanism. The "Aggresi= ve" is mis-spelled, should be "Aggressive". In the 1st paragraph, it says "= The initiator SHOULD continually send I1 and I2 packets at some short inter= val t msec, based on local policy." It is a bit ambiguous about " local pol= icy". 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. O= therwise, K value may be too big, implying high difficulty and significant = energy consumption.
6. Page 14, Section 4.1.4.2.  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. Si= nce parameters are encoded in TLV, I don't know why the table uses "Data" a= s the name of the 4th column. "Value" is clearer to understand the abbrevia= tion TLV. The content in the 4th cell of the 2nd row misused two conjunctio= n words "Encrypted container of for key generation..."
8. Page 15, Secti= on 5.1.1. HIT_SUITE_LIST, the HIT suites in DEX has no ID for ECDSA/DEX, bu= t 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 th= e maximum payload is 102 bytes in a MAC frame after headers (RFC 4944, Sect= ion 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 unnecess= ary to build this feature. A storm of I1 indicates DOS attack considering t= he average simultaneous link channels (<=3D 8 typically in TDMA) in most= of WSN applications. Moreover, due to the memory constraint, the packet bu= ffer 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  aut= hentication password..." --> "... configured with an  authenticatio= n password..."; "... it constructs the autentication response..." --> ".= .. it constructs the authentication response..."
12. Do you have any bet= a implementation work or micro benchmarking of HIP DEX? And micro benchmark= ing papers on HIP BEX. I'm interested in its performance and overhead analysis.

Thanks for your consideration and effort :)

BR
= niepin



=0A=0A=0A=0A=0A=0A=0A   --0-1714191536-1295272441=:11195--