[Hipsec] Mirja Kühlewind's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
Mirja Kühlewind <ietf@kuehlewind.net> Thu, 10 May 2018 10:00 UTC
Return-Path: <ietf@kuehlewind.net>
X-Original-To: hipsec@ietf.org
Delivered-To: hipsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2827B12EAAE; Thu, 10 May 2018 03:00:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kühlewind <ietf@kuehlewind.net>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-hip-native-nat-traversal@ietf.org, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, hip-chairs@ietf.org, gonzalo.camarillo@ericsson.com, hipsec@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.80.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152594644511.10319.6725951114596483825.idtracker@ietfa.amsl.com>
Date: Thu, 10 May 2018 03:00:45 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/reiIHR4u5pF_rpvcNtJQeMUV-KQ>
Subject: [Hipsec] Mirja Kühlewind's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 May 2018 10:00:45 -0000
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] Mirja Kühlewind's Discuss on draft-ietf-… Mirja Kühlewind
- Re: [Hipsec] Mirja Kühlewind's Discuss on draft-i… Miika Komu
- Re: [Hipsec] Mirja Kühlewind's Discuss on draft-… Mirja Kuehlewind