[Tsv-art] TSV-ART Review of draft-ietf-hip-native-nat-traversal

Colin Perkins <csp@csperkins.org> Mon, 26 February 2018 23:13 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B21612D947; Mon, 26 Feb 2018 15:13:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMnwHU1VAAOK; Mon, 26 Feb 2018 15:13:25 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB6412D946; Mon, 26 Feb 2018 15:13:25 -0800 (PST)
Received: from [81.187.2.149] (port=37075 helo=[192.168.0.71]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <csp@csperkins.org>) id 1eqRxT-0002MU-SY; Mon, 26 Feb 2018 23:13:24 +0000
From: Colin Perkins <csp@csperkins.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <9552714B-683F-4D71-A96C-C4C562B62873@csperkins.org>
Date: Mon, 26 Feb 2018 23:13:21 +0000
Cc: tsv-art@ietf.org
To: draft-ietf-hip-native-nat-traversal.all@ietf.org
X-Mailer: Apple Mail (2.3273)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/eFfyeBbDF36WaLJe5I10OSM-m9E>
Subject: [Tsv-art] TSV-ART Review of draft-ietf-hip-native-nat-traversal
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Feb 2018 23:13:27 -0000

Hi,

I've reviewed this document as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@… if you reply to or forward this review.

Summary:
This draft is basically ready for publication, but has nits that should be fixed before publication.

Comments:
This draft describes how the ICE algorithm can be applied for NAT traversal with the Host Identity Protocol (HIP). The classical ICE algorithm is tied to STUN and TURN for connectivity checks, encapsulation, and tunnelling. This draft recasts ICE to work with HiP-specific mechanisms. The proposed mechanism looks to be a straight-forward reworking of ICE into this new context, and there do not look to be any significant new transport issues raised compared to classic ICE.

The draft could perhaps better explain the rationale for recasting the ICE protocol to use HIP specific mechanisms rather than reusing STUN and TURN. In addition, the reference to Appendix B (which explains the differences from classical ICE) at the end of the Introduction could perhaps be highlighted. Both would be useful to show why this mechanism is needed, and to clearly document the differences to classical ICE.

The draft doesn’t mention the impact on the MTU of encapsulating HIP messages for NAT traversal. It probably should discuss the implications of this MTU reduction.

Section 4.1, page 11, suggests the use of UDP port 10500. The IANA considerations do not register this port. The draft should either register this port, or clearly cite the draft/RFC that does register it.

Regards,
Colin



-- 
Colin Perkins
https://csperkins.org/