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
