[hiprg] Tentative review of HIP DEX draft

[Peter Nick <[e-mail]>]

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 4.1.3.1 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 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. 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 :)

BR
niepin