Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt

Rene, Bob,

could you please have a look at Miika's comments below?

Thanks,

Gonzalo

On 28/03/2016 11:05 PM, Miika Komu wrote:
> 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 [RFC7401]) to the Initiator
>> before the Responder commences the ECDH operation.  The NOTIFY packet
>> serves as an acknowledgement for the I2 packet and consists of a
>> NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT
>> (see Section 5.2.19. in [RFC7401]).  The NOTIFICATION parameter
>> contains the anticipated remaining processing time for the I2 packet
>> in milliseconds as two-octet Notification Data.  This processing time
>> can, e.g., be estimated by measuring the computation time of the ECDH
>> key derivation operation at Responder boot-up.  After the I2
>> processing has finished, the Responder sends the regular R2 packet.
> 
> ( boot-up -> start-up procedures (it doesn't have to be a boot) )
> 
>> 4.1.2.3.  Simplified HIP State Diagram
> 
>> The following diagram shows the major state transitions.  Transitions
>> based on received packets implicitly assume that the packets are
>> successfully authenticated or processed.
> 
> Is the new NOTIFY illustrated also in the figure?
> 
>> 5.2.1.  DH_GROUP_LIST
>>
>> The DH_GROUP_LIST parameter contains the list of supported DH Group
>> IDs of a host.  It is defined in Section 5.2.6 of [RFC7401].  With
>> HIP DEX, the DH Group IDs are restricted to:
>>
>> Group                              KDF              Value
>>
>> NIST P-256 [RFC5903]               CKDF             7
>> NIST P-384 [RFC5903]               CKDF             8
>> NIST P-521 [RFC5903]               CKDF             9
>> SECP160R1  [SECG]                  CKDF             10
>> Curve25519 [RFC7748]               CKDF             11
>> Curve448   [RFC7748]               CKDF             12
>>
>> The ECDH groups 7 - 9 are defined in [RFC5903] and [RFC6090].  ECDH
>> group 10 is covered in [SECG] and Appendix D of [RFC7401].  These
>> curves, when used with HIP MUST have a co-factor of 1.
> 
> I suggest to change the "value" column title to "group id" or change the
> text
> as follows: "The ECDH groups with *values* 7 - 9..."
> 
>> The ECDH groups 11 and 12 are defined in [RFC7748].  These curves
>> have cofactors of 8 and 4 (respectively).
> 
> Same comment as previously.
> 
>> 5.2.3.  HOST_ID
>>
>> The HOST_ID parameter conveys the Host Identity (HI) along with
>> optional information about a host.  It is defined in Section 5.2.9 of
>> [RFC7401].
>>
>> HIP DEX uses the public portion of a host's static ECDH key-pair as
>> the HI.  Correspondingly, HIP DEX limits the HI algorithms to the
>> following profile:
> 
> I would add "*new* profile" since this is not part of RFC7401.
> 
>> 5.2.4.  HIT_SUITE_LIST
>>
>> The HIT_SUITE_LIST parameter contains a list of the supported HIT
>> suite IDs of the Responder.  Based on the HIT_SUITE_LIST, the
>> Initiator can determine which source HIT Suite IDs are supported by
>> the Responder.  The HIT_SUITE_LIST parameter is defined in
>> Section 5.2.10 of [RFC7401].
> 
>> The following HIT Suite IDs are defined for HIP DEX, and the
>> relationship between the four-bit ID value used in the OGA ID field
>> and the eight-bit encoding within the HIT_SUITE_LIST ID field is
>> clarified:
> 
> ...the following *new* HIT Suite IDs...
> 
> ...is clarified: -> ...is defined as follows:
> 
>> Note that the HIP DEX HIT Suite ID allows the peers to distinguish a
>> HIP DEX handshake from a HIPv2 handshake.  The Responder MUST respond
>> with a HIP DEX HIT suite ID when the HIT of the Initiator is a HIP
>> DEX HIT.
> 
> The details are a bit unclear. Which packet are you talking about here?
> 
> I mean the suite id is in R1 (and not in I1), so I guess you're
> referring that
> Responder must respond to I2 with an R2 that contains HIP DEX HITs?
> 
> In general, I'd urge the authors to write a separate "Compatibility with
> HIP base exchange" section in the end of the document with the two
> (problematic) use cases:
> 
> 1. Initiator=DEX, Responder=BEX
> 2. Initiator=BEX, Responder=DEX
> 
> How what happens in each case? Can the Initiator still try to
> communicate (in case the Responder could potentially support both
> protocols) or should it just abort? When exactly each party knows and
> from which parameters both of the parties detect incompatibilities?
> Consider also the opportunistic mode. Bits and pieces of this
> discussion was scattered here and there, but it would useful to recap
> this is one single section due to compatibility issues with RFC7401.
> 
>> 5.2.5.  ENCRYPTED_KEY
>>
>> [...]
>>
>> The ENCRYPTED_KEY parameter encapsulates a random value that is later
>> used in the session key creation process (see Section 6.3).  This
>> random value MUST have a length of at least 64 bit.  The puzzle value
>> #I and the puzzle solution #J (see [RFC7401]) are used as the
>> initialization vector (IV) for the encryption process.  To this end,
>> the IV is computed as FOLD(I | J, 128).  The AES-CTR counter is a 16
>> bit value that is initialized to zero with the first use.
> 
> The initialization vector is a explicit, separate field in RFC7401. Why
> I and J
> are implicitly reused here? To save bits?
> 
> The AES-CTR counter pops out a bit suddenly here. Perhaps you could
> "bridge" it to the text in a bit more smoother way.
> 
>> Once this encryption process is completed, the "encrypted value" data
>> field is ready for inclusion in the Parameter.  If necessary,
>> additional Padding for 8-byte alignment is then added according to
>> the rules of TLV Format in [RFC7401].
> 
> The key could be also included in ENCRYPTED parameter, which can
> accommodate multiple parameters... unless it is very important to
> keep the IV implicit.
> 
>> 5.3.  HIP Packets
>>
>> [...]
>>
>> In the future, an optional upper-layer payload MAY follow the HIP
>> header.  The Next Header field in the header indicates if there is
>> additional data following the HIP header.
> 
> RFC6078 is also future work.
> 
>> 5.3.1.  I1 - the HIP Initiator Packet
>>
>> [...]
>>
>> As a compression of the employed HIs, the Initiator's and the
>> Responder's HITs both determine the DH group ID that must be used in
>> order to successfully conclude the triggered handshake.  HITs,
>> however, only include the OGA ID identifying a HIP DEX HIT.  They do
>> not include information about the specific DH group ID of the
>> corresponding HI. [...]
> 
> Something wrong here, the first sentence is contradicting with the
> second and third one.
> 
>> 5.3.2.  R1 - the HIP Responder Packet
>>
>> [...]
>>
>> The R1 packet generation counter is used to determine the currently
>> valid generation of puzzles.  The value is increased periodically,
>> and it is RECOMMENDED that it is increased at least as often as
>> solutions to old puzzles are no longer accepted.
> 
> Section 6.1 describes: "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.
> 
> I guess R1 packet generation counters are still meaningful for the
> Initiator (despite Responder does not pre-generate R1s)?
> 
>> [...]
>>
>> The HOST_ID parameter depends on the received DH_GROUP_LIST parameter
>> and the Responder HIT in the I1 packet.  Specifically, if the I1
>> contains a Responder HIT, the Responder verifies that this HIT
>> matches the required DH group based on the received DH_GROUP_LIST
>> parameter.
> 
> "...included in the I1". Right?
> 
>> 5.3.3.  I2 - the Second HIP Initiator Packet
>>
>> [...]
>>
>> The HIP_CIPHER contains the single encryption transform selected by
>> the Initiator that it uses to encrypt the ENCRYPTED and ENCRYPTED_KEY
>> parameters.  The chosen cipher MUST correspond to one of the ciphers
>> offered by the Responder in the R1.  All implementations MUST support
>> the AES-CTR transform [RFC3686].
>>
>> [...]
>>
>> The TRANSPORT_FORMAT_LIST parameter contains the single transport
>> format type selected by the Initiator.  The chosen type MUST
>> correspond to one of the types offered by the Responder in the R1
>> packet.  Currently, the only transport format defined is the ESP
>> transport format [RFC7402].
> 
> Should all of the cipher suites and transport formats still be echoed
> to the Responder for security reasons? See also my next comment.
> 
>> 5.3.4.  R2 - the Second HIP Responder Packet
>>
>> [...]
>>
>> The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST,
>> and TRANSPORT_FORMAT_LIST parameters in the R2 packet.  These
>> parameters MUST be the same as included in the R1 packet. The
>> parameter are re-included here because the R2 packet is MACed and
>> thus cannot be altered by an attacker.  For verification purposes,
>> the Initiator re-evaluates the selected suites and compares the
>> results against the chosen ones.  If the re-evaluated suites do not
>> match the chosen ones, the Initiator acts based on its local policy.
> 
> Ok, so now the full list of parameters is included, so forget about my
> previous comment.
> 
>> 6.1.  Solving the Puzzle
>>
>> The procedures for solving and verifying a puzzle in HIP DEX are
>> strongly based on the corresponding procedures in HIPv2.  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.
> 
> in in -> in
> 
>> 6.2.1.  CMAC Calculation
>>
>> [...]
>>
>>
>> 5.  Set Checksum and Header Length fields in the HIP header to
>> original values.  Note that the Checksum and Length fields
>> contain incorrect values after this step.
> 
> I guess also the values following HIP_MAC should be restored since
> they were wiped in the step 2.
> 
>> 6.3.  HIP DEX KEYMAT Generation
> 
> (this section was a bit hard to understand)
> 
>> The HIP DEX KEYMAT process is used to derive the keys for the Master
>> Key SA as well as for the Pair-wise Key SA.  The keys for the Master
>> Key SA are based from the Diffie-Hellman derived key, Kij, produced
> 
> from -> on
> 
>> The keys of the Pair-wise Key SA are not directly used in the HIP DEX
>> handshake. [...]
> 
> used -> exposed in plaintext?
> 
>> Some payload protection mechanisms have their own
>> Key Derivation Function, and if so this mechanism SHOULD be used.
> 
> this -> such
> 
>> The HIP DEX KEYMAT process consists of two components, CKDF-Extract
>> and CKDF-Expand.  The Extract function compresses a non-uniformly
>> distributed key, as is the output of a Diffie-Hellman key derivation,
> 
> as is -> such as
> 
> 
>> The key derivation for the Master Key SA employs both the Extract and
>> Expand phases, whereas the Pair-wise Key SA MAY need both the Extract
>> and Expand phases if the key is longer than 128 bits.  Otherwise, it
>> only requires the Expand phase.
> 
> Suggest:
> 
> The key derivation for the Master Key SA employs always both the
> Extract and Expand phases. The Pair-wise Key SA needs only the Extract
> phase when key is smaller or equal to 128 bits, but otherwise requires
> also the Expand phase.
> 
>> The CKDF-Extract function is the following operation:
>>
>> CKDF-Extract(I, IKM, info) -> PRK
> 
> What does the arrow operator signify? I thought that it produces PRK,
> but PRK is actually defined below.
> 
>> where
>>
>> I          Random #I from the PUZZLE parameter
>> IKM        Input keying material, i.e., either the Diffie-Hellman
>>            derived key or the concatenation of the random values
>>            of the ENCRYPTED_KEY parameters in the same order as
>>            the HITs with sort(HIT-I | HIT-R)
> 
> So how to choose between the D-H key and ENCRYPTED_KEY? Use always the
> KEY if present, otherwise D-H?
> 
>> info       sort(HIT-I | HIT-R) | "CKDF-Extract"
> 
> Is "CKDF-Extract" an octet string?
> 
>> PRK        a pseudorandom key (of RHASH_len/8 octets)
>> |          denotes the concatenation
>>
>> The pseudorandom key PRK is calculated as follows:
>>
>> PRK     = CMAC(I, IKM | info)
> 
> Based on this, I don't really know how to extract key material (the
> arrow notation is confusing).
> 
>> The CKDF-Expand function is the following operation:
>>
>> CKDF-Expand(PRK, info, L) -> OKM
> 
> What does the arrow mean?
> 
> Maybe name "info" as "info2" because it is different variable.
> 
>> where
>>
>> PRK      a pseudorandom key of at least RHASH_len/8 octets
>>          (either the output from the extract step or the
>>          concatenation of the random values of the
>>          ENCRYPTED_KEY parameters in the same order as the
>>          HITs with sort(HIT-I | HIT-R))
> 
> How to choose between the extract output vs encrypted key?
> 
> Maybe you should rename this as "PRK2" in order to distinguish the
> variable from the Extract phase.
> 
>> info     sort(HIT-I | HIT-R) | "CKDF-Expand"
> 
> Is "CKDF-Expand" an octet string?
> 
>> L        length of output keying material in octets
>>          (<= 255*RHASH_len/8)
>> |        denotes the concatenation
>>
>> The output keying material OKM is calculated as follows:
>>
>> N       =  ceil(L/RHASH_len/8)
>> T       =  T(1) | T(2) | T(3) | ... | T(N)
>> OKM     =  first L octets of T
>>
>> where
>>
>> T(0) = empty string (zero length)
>> T(1) = CMAC(PRK, T(0) | info | 0x01)
>> T(2) = CMAC(PRK, T(1) | info | 0x02)
>> T(3) = CMAC(PRK, T(2) | info | 0x03)
>> ...
> 
> The Expand was a bit more clear, but still didn't understand how to get
> to the
> Expanded key material due the arrow notation.
> 
>> (where the constant concatenated to the end of each T(n) is a
>> single octet.)
> 
> Is there a max value?
> 
>> The initial keys are drawn sequentially in the order that is
>> determined by the numeric comparison of the two HITs, with the
>> comparison method described in the previous paragraph.  HOST_g
>> denotes the host with the greater HIT value, and HOST_l the host with
>> the lower HIT value.
> 
> This is just for Master keys, right?
> 
>> The number of bits drawn for a given algorithm is the "natural" size
>> of the keys.  For the mandatory algorithms, the following sizes
>> apply:
>>
>> AES  128 or 256 bits
> 
> I would clarify that this depends on the negotiated HIP_CIPHER.
> 
>> 6.5.  Processing Incoming I1 Packets
>>
>> 5.  If the received Responder's HIT in the I1 packet is not NULL, the
>> Responder's in the R1 packet HIT MUST match the destination HIT
> 
> ...the Responder's HIT in the R1 packet MUST match...
> 
>> 6.6.  Processing Incoming R1 Packets
>>
>> [...]
>>
>> 1.   A system receiving an R1 MUST first check to see if it has sent
>> an I1 packet to the originator of the R1 packet (i.e., it has a
>> HIP association that is in state I1-SENT and that is associated
>> with the HITs in the R1).  Unless the I1 packet was sent in
>> opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP
>> addresses in the received R1 packet SHOULD be ignored by the R1
>> processing and, when looking up the right HIP association, the
> 
> right -> correct
> 
>> 8.   The R1 packet may have the A-bit set - in this case, the system
>> MAY choose to refuse it by dropping the R1 packet and returning
>> to state UNASSOCIATED.  The system SHOULD consider dropping the
>> R1 packet only if it used a NULL HIT in the I1 packet.
> 
> I didn't understand the logic in the last sentence.
> 
>> Note that step 4 from the original processing rules of HIPv2
>> (signature verification) has been removed in the above processing
>> rules for HIP DEX.  Moreover, step 7 of the HIPv2 processing rules
>> has been adapted to account for the fact that HIP DEX uses ECDH
>> public keys as HIs.
> 
> Step 7 in the *original* processing rules, what is the ordinal in DEX?
> It is not 7.
> 
>> 6.7.  Processing Incoming I2 Packets
>>
>> [...]
>>
>> 5.   If the system's state machine is in the I2-SENT state, the
>> system MUST make a comparison between its local and sender's
>> HITs (similarly as in Section 6.3).  If the local HIT is smaller
>> than the sender's HIT, it should drop the I2 packet, use the
>> peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce
>> #I from the R1 packet received earlier, and get the local
>> Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J
>> from the I2 packet sent to the peer earlier.  Otherwise, the
>> system should process the received I2 packet and drop any
>> previously derived Diffie-Hellman keying material Kij and
>> ENCRYPTED_KEY keying material it might have generated upon
>> sending the I2 packet previously.  The peer Diffie-Hellman key,
>> ENCRYPTED_KEY, and the nonce #J are taken from the just arrived
>> I2 packet.  The local Diffie-Hellman key, ENCRYPTED_KEY keying
>> material, and the nonce #I are the ones that were sent earlier
>> in the R1 packet.
> 
> Please replace "sender" with "peer" (or remote host) in this section
> for more symmetric terminology.
> 
> get -> obtain
> 
>> 11.  The implementation SHOULD also verify that the Initiator's HIT
>> in the I2 packet corresponds to the Host Identity sent in the I2
>> packet.  (Note: some middleboxes may not be able to make this
>> verification.)
> 
> Why SHOULD? Why not MUST? I think we're talking about end-hosts here
> anyway.
> 
>> Note that steps 11 (encrypted HOST_ID) and 15 (signature
>> verification) from the original processing rules of HIPv2 have been
>> removed in the above processing rules for HIP DEX.  Moreover, step 10
>> of the HIPv2 processing rules has been adapted to account for
>> optional extension of the retransmission mechanism.  Step 16 has been
>> added to the processing rules.
> 
> ...in this document.
> 
>> 6.10.  Processing UPDATE, CLOSE, and CLOSE_ACK Packets
> 
>> UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in HIP DEX
>> as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 of [RFC7401]).
>> The only difference is the that the HIP_SIGNATURE is never present
>> and, therefore, is not required to be processed by the receiving
>> party.
> 
> How does rekeying work with the extract and expand functions?
> 
>> 6.11.  Handling State Loss
> 
>> Implementors MAY choose to use non-volatile, secure storage for HIP
>> states in order for them to survive a system reboot.  If no secure
>> storage capabilities are available, the system SHOULD delete the
>> corresponding HIP state, including the keying material.  If the
>> implementation does drop the state (as RECOMMENDED), it MUST also
>> drop the peer's R1 generation counter value, unless a local policy
>> explicitly defines that the value of that particular host is stored.
>> An implementation MUST NOT store a peer's R1 generation counters by
>> default, but storing R1 generation counter values, if done, MUST be
>> configured by explicit HITs.
> 
> MUST NOT -> SHOULD? Otherwise the part after this is kinda void.
> 
>> 7.  HIP Policies
> 
>> There are a number of variables that will influence the HIP exchanges
>> that each host must support.  All HIP DEX implementations SHOULD
>> provide for an ACL of Initiator's HI to Responder's HI.  This ACL
>> SHOULD also include preferred transform and local lifetimes.
>> Wildcards SHOULD also be supported for this ACL.
> 
> Why ACLs are mandatory?
> 
> ACL -> ACL consisting of
> 
>> The value of #K used in the HIP R1 must be chosen with care.  Values
>> of #K that are too high will exclude clients with weak CPUs because
>> these devices cannot solve the puzzle within a reasonable amount of
>> time. #K 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.
> 
>> 8.  Security Considerations
> 
>> o  The HIP DEX HIT generation may present new attack opportunities.
> 
> They cannot be used in ACLs. Maybe this could be mentioned. Can this
> be mitigated by always using full HIs?
> 
> 
> Some additional comments related to Appendix:
> 
> I think you could reference the SLIMFIT extension from Rene Hummen in
> the appendix. And possibly mention the following related work
> extending DEX that was done in the context of Convince Celtic+
> project:
> 
> P. Porambage, A. Braeken, P. Kumar, A. Gurtov and M. Ylianttila,
> "Efficient Key Establishment for Constrained IoT Devices with
> Collaborative HIP-Based Approach," 2015 IEEE Global Communications
> Conference (GLOBECOM), San Diego, CA, 2015, pp. 1-6.  doi:
> 10.1109/GLOCOM.2015.7417094
> 
> The work includes also benchmarks on energy consumption.
> 
> P.S. My review can be credited to Convince Celtic+.
> 
> 
> 
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
> 