Skip to main content

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

Yes


No Objection

(Alissa Cooper)
(Deborah Brungard)
(Martin Vigoureux)
(Robert Wilton)
(Suresh Krishnan)

Note: This ballot was opened for revision 30 and is now closed.

Éric Vyncke
Yes
Comment (2020-07-14 for -31) Sent for earlier
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.
Erik Kline
No Objection
Comment (2020-07-16 for -31) Not sent
Trusting previous AD's review.
Roman Danyliw
No Objection
Comment (2020-03-03 for -30) Sent
** 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/
Warren Kumari
No Objection
Comment (2020-03-03 for -30) Not sent
Re-applying my ballot position from previous. This is largely based on the OpsDir review.
Adam Roach Former IESG member
No Objection
No Objection (2020-02-24 for -30) Sent
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.
Alissa Cooper Former IESG member
No Objection
No Objection (for -30) Not sent

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2020-03-03 for -30) Sent
Just for completeness, this document should be tagged as Replacing draft-keranen-hip-native-nat-traversal.
Barry Leiba Former IESG member
No Objection
No Objection (2020-03-04 for -30) Sent
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.
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2020-07-15 for -31) Sent
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"?
Deborah Brungard Former IESG member
No Objection
No Objection (for -30) Not sent

                            
Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection (2020-07-28 for -32) Sent
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.
Martin Duke Former IESG member
(was Discuss) No Objection
No Objection (2020-07-27 for -32) Sent
Thank you for an easy-to-read document -- and for addressing my DISCUSS!
Martin Vigoureux Former IESG member
No Objection
No Objection (for -30) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2020-02-26 for -30) Sent
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.
Robert Wilton Former IESG member
No Objection
No Objection (for -31) Not sent

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -30) Not sent