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

Rene, Bob,

when we agreed to add this draft to our charter it was based on your
promise that you were going to be putting enough cycles into it. I
assume that is still the case and you have allocated enough time to push
this draft to completion, is that right?

Please, let us know when you will be able to address Miika's comments below.

Thanks,

Gonzalo

On 18/04/2016 3:55 PM, Gonzalo Camarillo wrote:
> 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
>>
> 
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
> 