[Hipsec] Roman Danyliw's No Objection on draft-ietf-hip-native-nat-traversal-30: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-hip-native-nat-traversal-30: 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:
----------------------------------------------------------------------

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