Note: This ballot was opened for revision 30 and is now closed.
The -31 version addresses all DISCUSSs and COMMENTs raised during the May 2018 first ballot on version -28 and in March 2020 2nd ballot on version -30.
** Section 6.1. Per “Also, revealing host addresses exposes information about the local topology that may not be allowed in all corporate environments.”, concur with the sentiment. However, this desire to reduce exposure may be beyond just “corporate” environment – recommend dropping the “corporate” modifier. ** Section 6.1. Per “For these two local policy reasons, an end-host MAY exclude certain host addresses from its LOCATOR_SET parameter, but this requires further experimentation.”, what actions should implementers take from the “this requires further experimentation”? ** Section 6.2. Per “In opportunistic HIP mode (cf. Section 4.1.8 in [RFC7401]), an Initiator sends an I1 with without setting the destination HIT of the Responder”, the text conflicts on whether to send the destination HIT – it likely should say “without the destination HIT” (i.e., “initial I1 packet contains all zeros as the destination HIT” per RFC7401). ** Section 6.3. Could the reference to [HIP-MIDDLE] be clarified: -- The reference says its: “Heer, T., Wehrle, K., and M. Komu, "End-Host Authentication for HIP Middleboxes", Work in Progress, February 2009”. Is that the same as draft-heer-hip-middle-auth-04, from October 2011? -- How much confidence is there in making this recommendation to an unpublished, expired experimental draft? ** Editorial Nits important for clarity in security considerations: -- Section 5.8. s/Similarly as with RVS_HMAC, also RELAY_HMAC is keyed .../Similarly as with RVS_HMAC, RELAY_HMAC .../ -- Section 6.1. Editorial. s/Especially, this could be problematic with a …/This could be especially problematic with a …/ Section 6.1. Recommend being clearing on the privacy and DoS protection by: s/This partially protects the …/This use also partially protects the …/ -- Section 6.7 Editorial. Recommend clarification how HIP is immune to the Section 19.2 of RFC8445 attack with: s/HIP bases its control plane security on Diffie-Hellman key exchange, public keys and Hashed Message Authentication codes, meaning that the mentioned security concerns do not apply to HIP either./ As HIP bases its control plane security on Diffie-Hellman key exchange, public keys and Hashed Message Authentication codes, this attack is mitigated in this protocol./ -- Section 6.7. Editorial. s/The mentioned section discusses also of …/ Section 19.2 of [RFC8445] also mentioned also discusses …/ -- Section 6.7. Editorial. Recommend referencing the text of the connectivity check that prevents the MiTM replay attack: s/The connectivity checks in this protocol are immune … and send back as a response./ The connectivity checks in this protocol are immune … and send back as a response per Section 4.6.1./ Editorial Nits -- Section 1. Editorial. Per “Also, especially NATs usually …” reads awkwardly to me – perhaps “Also, NATs usually ..” -- Section 1. Editorial. Per “… so that basically ICE is responsible for NAT traversal …” reads colloquially – perhaps “so that ICE is responsible for NAT traversal …” -- Section 1. Editorial. Per “Similarly as Legacy ICE-HIP, also this specification …”, it might be more readable as “As with Legacy ICE-HIP, this specification …” -- Section 2. Typo. s/prodecure/procedure/ -- Section 2. Typo. s/the the/the/ -- Section 3. Typo. s/Cotrol/Control/ -- Section 5.6. Typo. s/reserved/reserved/ -- Section 6.5. Typo. s/a another/another/ -- Section 7. Typo. s/emphemeral/ephemeral/
Thank you for an easy-to-read document -- and for addressing my DISCUSS!
Thanks for addressing the potential "cross-message" attack on the HMAC contents of RELAY_HMAC/RVS_HMAC by prohibiting the Control Relay Server from offering the rendezvous services. I think in order for the protection against the attack to be complete, though, we need to say that a HIP peer attempting to reach a Control Relay Server MUST reject any messages appearing to originate from that server, that contain an RVS_HMAC parameter. That is, the current text will keep honest actors from generating the bad situation, but we also want to protect ourselves against accepting input from a bad actor attempting to cause the bad situation. Thank you as well for addressing all of my other comments on the -30. They seem generally satisfactory, and my apologies for not responding to them sooner. I just have two remaining remarks: Section 1 tunneling overhead). Another solution is specified in [RFC5770], which will be referred to "Legacy ICE-HIP" in this document. The nit: s/to/to as/ Section 4.6.2 [RFC7401] section 5.3.5 states that UPDATE packets have to include either a SEQ or ACK parameter (but can include both). According to the RFC, each SEQ parameter should be acknowledged separately. In I don't see anything to support "acknowledged separately"; on the contrary, I see "A host MAY choose to acknowledge more than one UPDATE packet at a time; e.g., the ACK parameter may contain the last two SEQ values received, for resilience against packet loss." Perhaps the intent was "each SEQ parameter needs to be explicitly acknowledged"?
Trusting previous AD's review.
Re-applying my ballot position from previous. This is largely based on the OpsDir review.
Thanks for addressing my discuss points and most of my other comments. I believe the following comments from my previous ballot are still valid: I agree with other ADs that it is not clear to me why this mechanism is needed in addition RFC5770. This is a use case for ICE and I would think that re-using existing code and library would make implementation easier, faster and less error-prone. I especially agree to the comments from Adam! Other comments: 4) sec 4.8: "When a host does not receive acknowledgments, e.g., to an UPDATE or CLOSE packet after a timeout based on local policies, a host SHOULD resend the packet through the associated Data Relay Server of the peer (if the peer listed it in its LOCATOR_SET parameter in the base exchange." I did not really find anything about this in section 5.10 of RFC5770. In think the timeout needs to be further specified.
Given this document’s dependency on concepts and terminology from 5770, I think that document has to be a normative reference. Can someone really understand and implement this without any reference to 5770? — Abstract — The main difference from the previously specified modes is the use of HIP messages instead of ICE for all NAT traversal procedures due to its kernel-space dependencies. The antecedent to “its” is unclear: it could be “use of HIP messages”, or “ICE”, or “NAT traversal”. Please rephrase to clarify. — Section 1 — Also, especially NATs usually require the host behind a NAT to create a forwarding state in the NAT before other hosts outside of the NAT can contact the What does “especially” mean in this sentence? It doesn’t make sense to me. Does it add anything? which will be referred as "Legacy ICE-HIP" in this document. Nit: “referred to” HIP poses a unique challenge to using standard ICE, due not only to its kernel-space implementation, but also due to its close Same comment about “its” as in the abstract: please replace “its” with what you’re talking about, as it isn’t clear.
Just for completeness, this document should be tagged as Replacing draft-keranen-hip-native-nat-traversal.
Thanks to the authors for taking some of the concerns I laid out in my original ballot into account. I still do not believe this approach is good for HIP's benefit, but am no longer worried about collateral damage from other protocols imitating this approach. Accordingly, I am balloting "No Objection." There is one remaining comment from my initial review that I think can and should be addressed prior to publication: Appendix B: > o Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP > protocol in order to avoid middlebox tampering. This bullet should explain why such obfuscation is unnecessary.
Thanks for resolving and answering my questions. I have only one minor comment that I noticed due to that you edit the text: Section 2: "Following [RFC5770] and SDP [RFC3264] ..." RFC 3264 is not SDP, it is the "Offer/Answer model with SDP" there is a significant difference, as SDP base spec is RFC4566.