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

[Mirja Kuehlewind <[e-mail]>]

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 <miika.komu=[e-mail]> 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.
>