Alissa Cooper has entered the following ballot position for draft-ietf-hip-native-nat-traversal-28: 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-native-nat-traversal/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I admit to not having much familiarity with HIP, so apologies if some of these questions seem off-base. Why is this document on the standards track when RFC 5770 was experimental? Section 6.1 says: "The locators are in plain text format in favor of inspection at HIP- aware middleboxes in the future. The current document does not specify encrypted versions of LOCATOR_SETs, even though it could be beneficial for privacy reasons to avoid disclosing them to middleboxes." This seems to cut in the opposite direction of some of the other work we have going on in the IETF, where the justification for maintaining header information in the clear is for backwards-compatability with existing middleboxes, not to facilitate some to-be-developed middlebox behavior. Why is this justified for HIP? Section 6.1 also says "an end-host may exclude certain host addresses from its LOCATOR_SET parameter," but I don't think this is totally clear in Section 4.5 where it talks about "all the HIP candidates." I also wonder if it would be possible to provide some guidance about the circumstances under which an initiator might choose to exclude certain addresses, e.g. if there is a common deployment scenario where it's clear that certain candidates are meant to remain private. Nits: = Section 1 = " As one solution, the HIP experiment report [RFC6538] mentions that Teredo based NAT traversal for HIP and related ESP traffic (with double tunneling overhead)." This is a sentence fragment. = Section 2 = The paragraph about RFC2119 should also reference RFC8174. _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
