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. _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
