Hi,
> 1.1. The HIP Diet EXchange (DEX)
> Data packets start to flow after the 4th packet. The 3rd and 4th HIP
> packets may carry data payload in the future. However, the details
> of this may be defined later.
Similarly as in RFC7401, data packets start to flow...
(I guess you could also mention RFC6078 as another further work item)
> An existing HIP association can be updated with the update mechanism
> defined in [RFC7401]. Likewise, the association can be torn down
> with the defined closing mechanism for HIPv2 if it is no longer
> needed. HIP DEX thereby omits the HIP_SIGNATURE parameters of the
> original HIPv2 specification.
Why "thereby"? I don't see the connection.
> HIP DEX does not have the option to encrypt the Host Identity of the
> Initiator in the 3rd packet. The Responder's Host Identity also is
> not protected. Thus, contrary to HIPv2, there is no attempt at
> anonymity.
The anonymous bit still exists, so I suggest changing the wording:
there is no attempt at anonymity -> such Responder anonymity is not
preserved in HIP DEX.
> 2.1. Requirements Terminology
In section 6.3, you are introduce also -> notation, which was
not explained.
> 2.3. Definitions
I suggest to add also the definitions of both MAC and CMAC because they
are used throughout the document. They are also used in this section.
> 3.1. Host Identity Tag (HIT)
Just thinking aloud... should a DEX HIT have a different context ID?
Probably not.
> 4.1. Creating a HIP Association
> The HIP Diet EXchange serves to manage the establishment of state
> between an Initiator and a Responder. The first packet, I1,
> initiates the exchange, and the last three packets, R1, I2, and R2,
> constitute an authenticated Diffie-Hellman [DH76] key exchange for
> the Master Key SA generation. This Master Key SA is used by the
> Initiator and the Responder to wrap secret keying material in the I2
> and R2 packets. Based on the exchanged keying material, the peers
> then derive a Pair-wise Key SA if cryptographic keys are needed,
> e.g., for ESP-based protection of user data.
(Suggest replacing "user data" with e.g. "data plane" in the entire
document since you're talking about machines (sensors) that may not
have a user)
> In the I2 packet, the Initiator MUST display the solution to the
> received puzzle. Without a correct solution, the I2 packet is
> discarded. The I2 also contains a key wrap parameter that carries a
> secret keying material of the Initiator. This keying material is
> only half the final session key. The packet is authenticated by the
> sender (Initiator) via a MAC.
...half *of* the...
> The R2 packet acknowledges the receipt of the I2 packet and completes
> the handshake. The R2 contains a key wrap parameter that carries the
> rest of the keying material of the Responder. The packet is
> authenticated by the sender (Responder) via a MAC.
key wrap parameter -> parameter with encrypted contents
> 4.1.1. HIP Puzzle Mechanism
>
> The puzzle mechanism enables a Responder to immediately reject an I2
> packet if it does not contain a valid puzzle solution. To verify the
> puzzle solution, the Responder only has to compute a single CMAC
> operation. After a successful puzzle verification, the Responder can
> securely create session-specific state and perform CPU-intensive
> operations such as a Diffie-Hellman key generation. By varying the
> difficulty of the puzzle, the Responder can frustrate CPU or memory
> targeted DoS attacks.
...can frustrate *an Initiator*...
> Conceptually, the puzzle mechanism in HIP DEX is the same as in
> HIPv2. Hence, this document refers to Sections 4.1.1 and 4.1.2 in
> [RFC7401] for more detailed information about the employed mechanism.
> Notably, the only difference between the puzzle mechanism in HIP DEX
> and HIPv2 is that HIP DEX uses CMAC instead of a hash function for
> solving and verifying a puzzle. The implications of this change on
> the puzzle implementation are discussed in Section 6.1.
The other difference is mentioned in section 6.1:
"The only exceptions are that HIP DEX does not use pre-computation of
R1 packets and that RHASH is set to CMAC. As a result, the pre-
computation step in in Section 6.3 of [RFC7401] is skipped in HIP DEX."
> 4.1.2.1. HIP DEX Retransmission Mechanism
> The potentially high processing time of an I2 packet at a (resource-
> constrained) Responder may cause premature retransmissions if the
> time required for I2 transmission and processing exceeds the RTT-
> based retransmission timeout. Thus, the Initiator should also take
> the processing time of the I2 packet at the Responder into account
> for retransmission purposes. To this end, the Responder MAY notify
> the Initiator about the anticipated delay once the puzzle solution
> was successfully verified and if the remaining I2 packet processing
> incurs a high processing delay. The Responder MAY therefore send a
> NOTIFY packet (see Section 5.3.6. in
