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

[Miika Komu <[e-mail]>]

Hi Mirja,

thanks for your comments! My response is below, let me know if you have
further concerns.

to, 2018-05-10 kello 03:00 -0700, Mirja Kühlewind kirjoitti:
> 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).

IANA section should describe this:

   This document reuses the same default UDP port number 10500 as
   specified by Legacy ICE-HIP [RFC5770] for tunneling both HIP control
   plane and data plane traffic.  The selection between Legacy ICE-HIP
   and Native ICE-HIP mode is negotiated using NAT_TRAVERSAL_MODE
   parameter during the base exchange.

Let me know if something needs to be added.

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

Because it used to be like that in an earlier version of ICE. Good
catch, I have now changed SHOULD to MUST now.

> 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.

thanks, both are now "MUST"s.

> 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

aligned with RFC8085 as you requested:

 In this case, it is recommended that the hosts
   estimate the round-trip time (RTT) between them and SHOULD set the
   minimum Ta value so that at most a single connectivity check message
   is sent on every RTT.

> -------------------------------------------------------------------
> ---
> 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!

ICE was not designed with IPsec in mind, so the performance overhead is
unacceptable. I have also some additional reasoning for Adam Roach
here:


https://mailarchive.ietf.org/arch/msg/hipsec/Lx3SLQVaHI2ZKsMP8xxT27RMEn8

and here:


https://mailarchive.ietf.org/arch/msg/hipsec/tJ4evwlPEWOEHsRXLjFVlQS-ykE

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

It should read "nomination *of* an address". I changed the MAY to
SHOULD:

Upon successful nomination of an
   address pair, a host MUST immediately stop sending such
   retransmissions.

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

good catch, corrected this.

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

done!

> 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.

section 4.8 is "Sending Control Packets after the Base Exchange". Do
you mean section 4.10 in RFC57700:

https://tools.ietf.org/html/rfc5770#section-4.10

...which is also suggests "timeout based on local policies".

> 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).

agreed, changed to SHOULD.

> 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.

I reflected your concerns by adding a disclaimer:
     
In general, estimating RTT can be difficult and error prone; further
experimentation is required for reliable RTT estimation.