[Hipsec] Iotdir last call review of draft-ietf-hip-dex-11

[Michael Richardson via Datatracker <[e-mail]>]

Reviewer: Michael Richardson
Review result: Ready

I am the assigned IoT-Directorate reviewer for 1draft-ietf-hip-dex
I reviewed the -11 version.

I did not identify any technical problems or gaps.
The introduction tells that I won't understand this without a good
understanding of RFC7401 (HIPv2).  I went ahead anyway, given that I did know
HIPv1 (RFC5201) and IKEv2.

While it is clear that I could not implement without knowing 7401, I did find
that I could understand most of the goals, the compromises that were made to
reduce the complexity for constrained environments.  I did go back and read
7401 in the end to fill in a few gaps.

Particularly I really needed to understand RFC7343 HITs of the new type, and
I did not manage to understand that part.  I observe that a new ECDH type of
HIT is defined, but I did understand how these values would be
exchanged/stored or looked up.

I would appreciate a use case or two which has been sufficiently built-out so
that I can see the whole picture. If ECDH HITs come from DNS (via AAAA
records) for instance, then I'd appreciate an understanding if/how the
constrained device is able to leverage DNSSEC.
In particular, I'd like to know what kind of applications are ruled out by
lack of PFS, and if a kind of PFS can be restored by rotating HITs in DNS.

Would this document play well with draft-ietf-ipsecme-implicit-iv?

I am unclear if the diet nature of DEX is more about:
  (1) constrained/challenged networks
  (2) constrained/slow CPUs
  (3) systems with very minimal amounts of flash

(1) networks have often very small packet sizes, and I would appreciate
understanding the total frame sise of each I1/R1/I2/R2, and any impact that
fragment assembly might have on the statelessness of the I1/R1 exchange.

I know that HIP has be profiled for use in 802.15.9, and I assume that HIP
DEX is even better, but the lack of PFS might be a show stopper.

(2) slow/sleepy CPUs are not going away, but the amount of available flash on
rather cheap, small and sleepy devices is now in the multiple megabytes, so
it is unclear if further code simplications are worthwhile.

My questions should not stop the document from advancing.