[Hipsec] Mirja Kühlewind's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-hip-native-nat-traversal-28: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1) This document should also update the IANA port registry to add a reference
to this RFC-to-be to the existing entry for port 10500 (eventually even with
note that this RFC-to-be discusses how to distinguish the services using
NAT_TRAVERSAL_MODE).

2) Sec 4.4: "Hosts SHOULD NOT use values smaller than 5 ms for the minimum
Ta,..." In rfc5245bis this is a MUST. Why is this a SHOULD here?

Also in sec 4.6.2.:
"If neither one of the hosts announced a minimum pacing value, a value of 50 ms
SHOULD be used." This must be a MUST to be inline with sec 4.4.

3) Appendix A: "Ta value so that only two connectivity check messages are sent
on every RTT." Why two? RFC8085 recommends (SHOULD) at may one packet per RTT
for non-congestion control transmissions


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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, fast and
less-error-prone. I especially agree to the comments from Adam!

Other comments/nits:

1) sec 4.6.2: "Upon successful nomination an address pair, a host MAY
immediately stop sending such retransmissions." Not sure I understand this
sentence; why MAY?

2) sec 4.1: The registration to the Control Relay Server can be achieved using
   RELAY_UDP_ESP parameter as explained later in this section."
I guess that should be RELAY_UDP_HIP?

3) sec 4.1: "It is RECOMMENDED that the Relay Client select a random port
number..." Please say source port -> s/random port number/random source port
number/

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.

5) sec 5.3: "It is worth noting that sending of such a HIP NOTIFY
   message MAY be omitted if the host is actively (or passively) sending
   some other traffic (HIP or ESP) "
This should really be a SHOULD (at least).

6) Appendix A: "One way to estimate the RTT is to use the time that it takes
for the Control Relay Server registration exchange to complete;" That does
estimate the RTT between the endhost... I not aware of a good way to estimate
that, so I'm actually not convinced that the recommendation in appendix A is
that useful at all.