[Hipsec] Comments on draft-hip-native-nat-traversal-19
Christer Holmberg <christer.holmberg@ericsson.com> Sun, 26 March 2017 00:34 UTC
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57197128896 for <hipsec@ietfa.amsl.com>; Sat, 25 Mar 2017 17:34:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 KsWgHjOag9cH for <hipsec@ietfa.amsl.com>; Sat, 25 Mar 2017 17:34:13 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 0949A128D3E for <hipsec@ietf.org>; Sat, 25 Mar 2017 17:34:12 -0700 (PDT)
X-AuditID: c1b4fb30-3efff7000000628e-2c-58d70c81c558
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 58.80.25230.18C07D85; Sun, 26 Mar 2017 01:34:11 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0339.000; Sun, 26 Mar 2017 01:34:09 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "hipsec@ietf.org" <hipsec@ietf.org>
Thread-Topic: Comments on draft-hip-native-nat-traversal-19
Thread-Index: AdKlx3D+K+wlmRkFTR6Gys+AEEsX0w==
Date: Sun, 26 Mar 2017 00:34:08 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB2C90B@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB2C90BESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM2K7t24zz/UIgwN/eS2mLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOl9u5gKTkxmrGj7sIK5gbGvqouRk0NCwERi6ZGFzF2MXBxC AusYJXr7trFBOEsYJd5NPgyU4eBgE7CQ6P6nDdIgIqAucbSnmQXEFhYwk/jXc5UJIm4tMeHv YjYIW09i79rpjCA2i4CqxLdeiHpeAV+J3puNYPWMAmIS30+tAbOZBcQlbj2ZzwRxkIDEkj3n mSFsUYmXj/+xQthKEmsPb2eBqM+XODbtABPETEGJkzOfsExgFJyFZNQsJGWzkJRBxHUkFuz+ xAZha0ssW/iaGcY+c+AxE7L4Akb2VYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiBwX9wy2+D HYwvnzseYhTgYFTi4TXYdy1CiDWxrLgy9xCjBAezkgiv4QGgEG9KYmVValF+fFFpTmrxIUZp DhYlcV7HfRcihATSE0tSs1NTC1KLYLJMHJxSDYz+DmGvvqa8NVz+SPibWfldu0YGhv3H1kp8 +2zP4K+weMOKg9N8i90+nphx7Ejjoey1OxxC3i0Nj7teZXnjnQe/26Vk24iHXq0//K8fuOql NefxNftnD09XTn47r4ep49Uh1thH+ZP3cks+MLmQs9lldxpP8nP/afsTpfndoxPnXrt2Y6u+ UYOZEktxRqKhFnNRcSIA9N5TgnoCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/6cYQ6HBffqNSgWQivCWUbtw20RM>
Subject: [Hipsec] Comments on draft-hip-native-nat-traversal-19
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Sun, 26 Mar 2017 00:34:16 -0000
Hi, As co-author for the ICEbis draft, I was asked to review draft-hip-native-nat-traversal-19. I have not had time to review the whole document. However, many of my comments are generic, and apply to the whole document. I have no knowledge of HIP, so I will not comment on HIP issues like messages, parameters etc used. General: ======= QG0: Throughout the document, you use RFC 2119 terminology (SHOULD, MUST etc with capital letters) when you refer to procedures and rules defined elsewhere. I think that is wrong, and it also makes it very difficult what exactly is defined in this document, and what is defined in some other specification. QG1: You say that the mechanism in the draft is based on ICE. I think it would be good to give a name to the mechanism. "HIP-ICE", or something similar. QG2: I would also like to have a dedicated section which on a high-level describes the differences/restrictions between legacy ICE and HIP-ICE. It helps very much when later reading the details in section 4. That section should at least list the different types of functions (HIP relays etc) are used for gathering candidates, what protocol (HIP messages) is used instead of STUN, what types of candidates are used and how they are retrieved. It would also be good to give a short overview of the HIP messages used for the connectivity checks. It is very useful when later reading the details. QG3: You should use consistent terminology when you talk about endpoints and relays. Sometimes the text says "host", sometimes "HIP relay server client", sometimes "relay client", sometimes "end-host". Sometimes you say "HIP relay", sometimes "HIP server relay", etc. Sometimes you say "non-relay host", which suggests that the relay is also a host. Section 3: ======== Q30: The text says: "The hosts may use HIP relay servers (or even STUN or TURN servers) for gathering the candidates." This is confusing, as you have earlier said that HIP-ICE doesn't use STUN. (Implementations may of course provide both STUN- and HIP functionality, but that is outside the scope of the document.) Q31: The text says: "To be contacted from behind a NAT, the Responder must be registered with a HIP relay server reachable on the public Internet, and we assume, as a starting point, that the Initiator knows both the Responder's Host Identity Tag (HIT) and the address of one of its relay servers" First, when you say "its relay servers", I assume you mean the relay servers of the Responder? Second, doesn't the Initiator need to know the address of the relay to which the Responder is actually registered, in case there are multiple relays but the Responder is not registered with all of them? Maybe someone thinks it's obvious, but I think it should be make clear. Could you simply say: "To be contacted from behind a NAT, the Responder must be registered with a HIP relay server reachable on the public Internet. It is assumed that the Initiator knows the address of the relay server(s) to which the Responder is registered." Q32: The section introduces the "base exchange" concept, but it is not clearly defined. Is it something defined in HIP, is it HIP-ICE specific? I think you should add a description/reference somewhere. Q33: The text says: "At the end of the procedure, if successful, the hosts will have established a UDP-based tunnel that traverses both NATs, with the data flowing directly from NAT to NAT or via a HIP data relay server." What if the responder has only registered to a HIP server relay? The text in the section seems to suggest that it is optional to register to a data relay. The text needs to be more clear on whether the endpoints need to register to a server relay and/or data relay. Section 4.2: ========== Q421: In general, I think it would be useful to split the section into HIP client procedures and HIP relay server procedures. Q422: I think the following text should be in the beginning of the section: "ICE guidelines for candidate gathering MUST be followed as described in section 4.1.1 in [I-D.ietf-ice-rfc5245bis]. A number of host candidates (loopback, anycast and others) should excluded as described in section 4.1.1.1 of the ICE specification [I-D.ietf-ice-rfc5245bis]." Q423: The text says: "However, if no data relay is used, and the host has only a single local IP address to use, the host MAY use the local address as the only host candidate" I am not sure what is meant by "as the only host candidate". Q424: The text says: "Relayed candidates SHOULD be gathered in order to guarantee successful NAT traversal. It is RECOMMENDED for implementations to support this functionality" If you say SHOULD use, why do you then only say RECOMMEND support? Doesn't the support need to be stronger than the usage? Q425: The text says: "Unlike ICE, this protocol only creates a single UDP flow between the two communicating hosts, so only a single component exists." This is confusing. What is meant by "unlike ICE"? You are using ICE :) I assume you are referring to ICE usage for non-multiplexed RTP/RTCP? I think you simply need to say that HIP only uses a single UDP flow, using a single component, with a value of 1. Section 4.3: ========== Q431: The text says: "This section describes the usage of a new non-critical parameter type." Shouldn't it say that the section defines a new parameter type? Q432: If I understand correctly, the NAT mode negotiation between an endpoint and a relay takes place during registration. But, when does the NAT mode negotiation between two endpoints (shown in the call flow) take place? During connectivity checks? I think you should clarify that. Section 4.6: ========== Q460:The text says: "but UDP encapsulated HIP control messages are used instead of ICE messages." What do you mean by "ICE messages"? STUN? Section 4.6.2: ============ Q4620: The text says: "The HITs of the two communicating hosts MUST be used as credentials in this protocol (in contrast to ICE which employs username-password fragments)." Again, "contrast to ICE" sounds confusing, because you are using ICE. Maybe you should say "legacy ICE", or something similar, when referring to 5245bis procedures. Section 4.7: ========== Q470: The name of the section ("NAT traversal alternatives") is confusing, because one may think it talks about something else than HIP-ICE. I would suggest to call it something like "Optimizations". Section 4.9: ========== Q490: I think Mobiliy should be described in a separate main section. Regards, Christer
- Re: [Hipsec] Comments on draft-hip-native-nat-tra… Miika Komu
- [Hipsec] Comments on draft-hip-native-nat-travers… Christer Holmberg