Hi Miika, Thanks for addressing my discuss points and comments. I just enter “No Objection” as my new ballot position.
Reading point 4 below: Yes I was referencing the wrong section. However, I still think it would be good to provide more guidance about who long a timeout should be. Mirja > On 19. Feb 2020, at 19:39, Miika Komu > <[email protected]> wrote: > > 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. > _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
