Hi Qin, I am stepping in and helping the authors to finalize this draft. On 3/2/18 20:15, Robert Moskowitz wrote: > > > On 02/23/2018 03:23 AM, Qin Wu wrote: >> Reviewer: Qin Wu >> Review result: Ready >> >> Summary: >> This document defines the Host Identity Protocol Diet EXchange (HIP >> DEX) protocol for constrained devices. The draft is well written. >> I believe >> it is ready for publication. >> Major issue: None >> Minor issue: Editorial >> 1.It is not clear how fine-grained policy control defined in IKEv2 is >> different >> from policy control defined in HIP DEX protocol? > > There is a long-standing difference in HIP to IKE policy. I am > "shooting from the hip" a bit here, as it has been years since having > this sort of discussion. For starters, HIP does not have policyu bound > to an interface IP address. Then there is the nature of parameters in > HIP DEX like the size of the cookie puzzle and how in some IOT cases, > this can actually be used as an attack so policy may be used to manage > this. Much is left to the implementer, it is true. https://tools.ietf.org/html/rfc7401#section-1.2 "The base protocol does not cover all the fine-grained policy control found in Internet Key Exchange (IKE) [RFC7296] that allows IKE to support complex gateway policies. Thus, HIP is not a complete replacement for IKE." >> In the draft, local policies >> are mentioned many times, however it is not clear what local policy >> for HIP DEX >> Protocol looks like? > > To this I have to defer to Rene, who has implemented DEX... RFC7401 lists some things relevant to local policies: https://tools.ietf.org/html/rfc7401#page-106 The relevant ones are repeated also in HIP DEX: https://tools.ietf.org/html/draft-ietf-hip-dex-06#section-7 >> Is it possbile to carry policy control parameters(e.g., >> ACL parameter) in the HIP DEX protocol message? > > HIP has avoided negotiating policies, and thus carrying them in > messages. I am working some drafts that does provide for limited policy > control parameters. agree with Robert, ACLs are not carried in HIP messages. >> Would it be great to provide example to clarify this. Section 7 lists policy examples (please check my earlier comment). >> 2. Is Nonce I same as radom value #I? yes, it is the same. I added to section 2.3. Definitions: Nonce #I and #J: Nonce #I and nonce #J refer to the corresponding fields in the PUZZLE parameter (see section 5.2.4 in [RFC7401]. They are also referred as "random value #I and #J" in this document. >> 3. Is puzzle difficulty K same as #K used in the HIP R1 described in section 7? this is correct. I clarified in section 2.3 Definitions: Puzzle difficulty K: The Initiator has to compute a solution for the puzzle. The level of computational difficulty is denoted by the #K field in the puzzle parameter (see section 5.2.4 in [RFC7401]. and section 7 (#K is now without the hash): The value of puzzle difficulty K used in the HIP R1 must be chosen with care. Values for the K that are too high will exclude clients with weak CPUs because these devices cannot solve the puzzle within a reasonable amount of time. The K value should only be raised if a Responder is under high load, i.e., it cannot process all incoming HIP handshakes any more. If a Responder is not under high load, K SHOULD be 0. >> 4. Is puzzle difficulty K same as low-order #K bits of the RHASH? no, K is the #K field in the puzzle parameter (as now clarified in the Definitions). It refers is the number of bits that should be zero when calculating the puzzle solution from the RHASH as mentioned in section 5.3.3 in the DEX draft: The low-order #K bits of the RHASH(I | ... | J) MUST be zero. >> If the answer is >> yes, please make the term and symbol used in the draft consistent. > > Good catch on this. I will check this over. I have now clarified the terms and their variants now in section 2.3, I hope this works for you? Thanks for your comments and I hope this resolves your concerns!
