[Hipsec] Martin Duke's No Objection on draft-ietf-hip-dex-24: (with COMMENT)

[Martin Duke via Datatracker <[e-mail]>]

Martin Duke has entered the following ballot position for
draft-ietf-hip-dex-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-hip-dex/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for providing detailed data on why this sort of security compromise is
necessary. I am not a crypto expert, but wonder if there is some way to
leverage the potentially asymmetric capabilities of two HIP nodes to offload
more of the computation onto one of them.

- This is optional, but some suggest replacing the term "man in the middle"
with "on-path attacker". Please do it if you are amenable.

- Does HIP DEX always put version 2 in the version field, or is DEX somehow
orthogonal to HIP version?

- Thanks for the discussion of the I2 retransmission timeout in Sec 9. It
addressed my concerns in reading Section 4. The "reported delay + 1/2 maximum
RTT" formula seems like an odd heuristic for what ought to be "the reported
delay plus a little more", but it *does* limit a spoofed NOTIFY to no more than
doubling the retransmission rate.