Re: [Hipsec] Mirja Kühlewind's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
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 > 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
Re: [Hipsec] Mirja Kühlewind's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
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,
[Hipsec] Mirja Kühlewind's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
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. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
