Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-33

Trusting previous AD's review.

** 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/

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.

Just for completeness, this document should be tagged as Replacing draft-keranen-hip-native-nat-traversal.

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.

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"?

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.

Thank you for an easy-to-read document -- and for addressing my DISCUSS!

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.

Re-applying my ballot position from previous. This is largely based on the OpsDir review.