Last Call Review of draft-ietf-hip-dex-11

Request Review of draft-ietf-hip-dex
Requested rev. no specific revision (document currently at 18)
Type Last Call Review
Team Internet of Things Directorate (iotdir)
Deadline 2019-11-30
Requested 2019-10-31
Requested by Éric Vyncke
Authors Robert Moskowitz, Rene Hummen, Miika Komu
Draft last updated 2019-11-24
Completed reviews Genart Last Call review of -06 by Francis Dupont (diff)
Secdir Last Call review of -06 by David Waltermire (diff)
Opsdir Last Call review of -06 by Qin Wu (diff)
Iotdir Last Call review of -11 by Michael Richardson (diff)
Secdir Last Call review of -11 by Donald Eastlake (diff)
Genart Last Call review of -11 by Francis Dupont (diff)
Dear IoT Directorate,

As the Diet version of HIP is specifically targeting a light version, I would appreciate it if the IoT directorate delivered a review from the IoT perspective.

I put a deadline after the IETF so plenty of time during and after the IETF last call

Thank you

Assignment Reviewer Michael Richardson
State Completed
Review review-ietf-hip-dex-11-iotdir-lc-richardson-2019-11-24
Posted at
Reviewed rev. 11 (document currently at 18)
Review result Ready
Review completed: 2019-11-24


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.