From nobody Fri May 4 12:34:35 2018 Return-Path: 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 C60FE1200C1; Fri, 4 May 2018 12:34:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: hipsec@ietf.org, Gonzalo Camarillo , hip-chairs@ietf.org, gonzalo.camarillo@ericsson.com, draft-ietf-hip-native-nat-traversal@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152546246777.11589.13288594519409569524.idtracker@ietfa.amsl.com> Date: Fri, 04 May 2018 12:34:27 -0700 Archived-At: Subject: [Hipsec] Eric Rescorla'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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 19:34:28 -0000 Eric Rescorla 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: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3099 I am very familiar with ICE and yet I found this document extremely hard to follow. The problem is that it cherry-picks pieces of ICE and I'm just not sure that it's a complete specification when put all together. I have noted a number of places where I actually am not sure how to implement something, and fixing those will resolve this DISCUSS, but IMO you really should totally rewrite this document either (a) as a variant of ICE or (b) as an entirely new document not with a pile of new text and then references out to ICE sections. DETAIL S 4.2. > request type SHOULD NOT create any state at the Control Relay Server. > > ICE guidelines [I-D.ietf-ice-rfc5245bis] for candidate gathering are > followed here. A number of host candidates (loopback, anycast and > others) should be excluded as described in the ICE specification > [I-D.ietf-ice-rfc5245bis]. Relayed candidates SHOULD be gathered in If you're going to normatively cherry-pick ICE, you need to note specific sections, I think. S 4.6.2. > > A host may receive a connectivity check before it has received the > candidates from its peer. In such a case, the host MUST immediately > generate a response, and then continue waiting for the candidates. A > host MUST NOT select a candidate pair until it has verified the pair > using a connectivity check as defined in Section 4.6.1. Are you supposed to put this on a TODO check list as with ICE? S 5.8. > > 5.8. RELAY_HMAC Parameter > > As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC parameter > value has the TLV type 65520. It has the same semantics as RVS_HMAC > [RFC8004]. What key is used for the HMAC? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 2. > Server reflexive candidate: > A translated transport address of a host as observed by a Control > or Data Relay Server. > > Peer reflexive candidate: > A translated transport address of a host as observed by its peer. You should indicate which definitions are the same as ICE/STUN S 3. > connected to the public Internet. To be contacted from behind a NAT, > at least the Responder must be registered with a Control Relay Server > reachable on the public Internet. The Responder may have also > registered to a Data Relay Server that can forward the data plane in > case NAT traversal fails. While, strictly speaking, the Initiator > does not need any Relay Servers, it may act in the other role with Why doesn't it need Relay Servers? This isn't true for ordinary ICE. S 4.1. > for that host and close the corresponding UDP port (unless other Data > Relay Clients are still using it). > > The Data Relay Server SHOULD offer a different relayed address and > port for each Data Relay Client because this can cause problems with > stateful firewalls (see Section 6.5). by "this" I think you mean "not doing so" S 4.2. > parameter discovered during the Control Relay Server registration as > a server reflexive candidate. In this case, no further candidate > gathering is needed. > > A Data Relay Client MAY register only a single relayed candidate to > be used with multiple other peers. However, it is RECOMMENDED that a Nit: this would be clearer if you said "that it uses with" S 4.2. > gathering is needed. > > A Data Relay Client MAY register only a single relayed candidate to > be used with multiple other peers. However, it is RECOMMENDED that a > Data Relay Client registers a new server reflexive candidate for each > of its peer for the reasons described in Section 4.12.3. The This sentence feels like a bit of a non-sequiter. How do you "register" a srflx? Or should this say "relayed" S 4.2. > deployments in order to enable it by software configuration update if > needed at some point. A host SHOULD employ only a single server for > gathering the candidates for a single HIP association; either one > server providing both Control and Data Relay Server functionality, or > one Control Relay Server and also Data Relay Server if the > functionality is offered by another server. When the relay service How does this interact with mult-layered NAT?> S 4.3. > Servers (e.g. in the case of a single server, it would be 1). A > smaller value than 500 ms for the RTO MUST NOT be used. > > 4.3. NAT Traversal Mode Negotiation > > This section describes the usage of a new non-critical parameter Can you name the type here please? S 5.6. > Protocol IANA assigned, Internet Protocol number. > 17 for UDP, 0 for plain IP > Reserved reserved for future use; zero when sent, ignored > when received > Address an IPv6 address or an IPv4 address in "IPv4-Mapped > IPv6 address" format Is there a concern about NATs rewriting these, as we had for XOR- MAPPED-ADDRESS S 5.7. > | Reserved | 0 | Reserved for future extensions | > | Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the | > | (P) bit | | Responder can use it for the rest of the | > | | | base exchange, otherwise set to zero | > | Locator | Variable | Locator lifetime in seconds | > | Lifetime | | | What is the purpose of this? It's not an ICE parameter. S 5.7. > | Port | | | > | Transport | Variable | IANA assigned, transport layer Internet | > | Protocol | | Protocol number. Currently only UDP (17) | > | | | is supported. | > | Kind | Variable | 0 for host, 1 for server reflexive, 2 for | > | | | peer reflexive or 3 for relayed address | Why do you need to send prflx candidates? S 10.2. > o If the agent is using Diffserv Codepoint markings [RFC2475] in its > media packets, it SHOULD apply those same markings to its > connectivity checks. > > o Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP > protocol in order to avoid middlebox tampering. I noted this earlier. Why? From nobody Sun May 6 10:20:11 2018 Return-Path: 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 6450B127873 for ; Sun, 6 May 2018 10:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 vBjCFXsKVvzC for ; Sun, 6 May 2018 10:20:03 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 7839C127876 for ; Sun, 6 May 2018 10:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525627199; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pbB9hW+B9YMedug8lARyvxcN+c3rRI4Wy6UIiK91U5s=; b=DElekIwotgS5TarGRAY5GI2isQW9XEttxOhY/edVvOKSLJJJOeFeEpEeuwDru2rg 5cvg5XqJBRDipX73KUHwz6tz15RFL/uceiFr/eeIs1S+5ft9wKoCATtQRZk9Fi06 WLwmVl6qrOrE5lZenrsaCIk1OkqTPXq4CpgM3+uJ9Lg=; X-AuditID: c1b4fb3a-d35ff7000000729c-d1-5aef393e9005 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C5.44.29340.E393FEA5; Sun, 6 May 2018 19:19:59 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0382.000; Sun, 6 May 2018 19:19:58 +0200 From: Christer Holmberg To: Eric Rescorla , The IESG CC: "hipsec@ietf.org" , "draft-ietf-hip-native-nat-traversal@ietf.org" , "hip-chairs@ietf.org" Thread-Topic: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT) Thread-Index: AQHT497tPndaPbfR0EuvRo85uzt3DKQi880Q Date: Sun, 6 May 2018 17:19:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72EB51CE@ESESSMB109.ericsson.se> References: <152546246777.11589.13288594519409569524.idtracker@ietfa.amsl.com> In-Reply-To: <152546246777.11589.13288594519409569524.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.171] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbFdS9fe8n2UQdNFdov2NR3MFiten2O3 ONLaxW4xddFkZosZfyYyO7B6LFnyk8lj8uM25gCmKC6blNSczLLUIn27BK6ME5ulC06zVTy9 85O5gXEKaxcjJ4eEgInEyjfb2EFsIYEjjBLtb+q7GLmA7EWMEj3nnjB3MXJwsAlYSHT/0wap ERGwknj1+xoLSA2zwE5GickvnzKDJIQFSiU+PdvKBlFUJvHr9wlWCNtI4uO0hWBxFgEVidOf trGBzOQV8JVoPeEKsddP4uHOaWDlnAL+Es8eP2cEsRkFxCS+n1rDBGIzC4hL3HoynwniZgGJ JXvOM0PYohIvH/+D+kVJ4sTDRmaIeh2JBbs/sUHY2hLLFr4Gi/MKCEqcnPmEZQKj6CwkY2ch aZmFpGUWkpYFjCyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQIj6OCW31Y7GA8+dzzEKMDB qMTDe1/5fZQQa2JZcWXuIUYJDmYlEd7t5kAh3pTEyqrUovz4otKc1OJDjNIcLErivE5pFlFC AumJJanZqakFqUUwWSYOTqkGRpYo91P6fqumuznWTH3/4/d7s0dWjquY9p63ErZJvT1/5Y/1 qiy7Mmr8JKIex/DqxVlzL0rnc2xq3uJXw/nOn5XZfrfi2f97hf4/79t5NmJNe06+aFaC71LO rJBFV7eek30w7Y3o1VOG9qzRJUuO6vfY1n3+pPfRrSjia5yuTfOTZVquZw7EKLEUZyQaajEX FScCAFSsxPGcAgAA Archived-At: Subject: Re: [Hipsec] Eric Rescorla'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 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2018 17:20:04 -0000 Hi, > I am very familiar with ICE and yet I found this document extremely hard = to follow. The problem is that it cherry-picks pieces=20 > of ICE and I'm just not sure that it's a complete specification when put = all together. I have noted a number of places where I=20 > actually am not sure how to implement something, and fixing those will re= solve this DISCUSS, but IMO you really should totally=20 > rewrite this document either (a) as a variant of ICE or (b) as an entirel= y new document not with a pile of new text and then=20 > references out to ICE sections. I haven't been involved in the work on this draft, so I may be wrong, but I= did review the document and my understanding is that RFC 5770 is the "vari= ant of ICE", and this document is a modification/extension to RFC 5770. Regards, Christer From nobody Sun May 6 12:01:46 2018 Return-Path: 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 7CB5812D7E2 for ; Sun, 6 May 2018 12:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 jkw4ebABjEA7 for ; Sun, 6 May 2018 12:01:42 -0700 (PDT) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4E2312D77C for ; Sun, 6 May 2018 12:01:42 -0700 (PDT) Received: by mail-ot0-x231.google.com with SMTP id j27-v6so29714853ota.5 for ; Sun, 06 May 2018 12:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6IATeeGJuy9tMvuZpaoaqImJDT16W9mW7DHo+qKzpZ4=; b=Zd7S7kSviw7/0nCBZm4ZgkaUd6/9mdZY11xU9tVQoCK2AF0NqndNcokch9jNPO6qv1 n7Bj3vMM+BMgp4R+SuSqfOOCNCUiOy0QVw8cYGdXpELQchCrBAj49jinbIBJfWMUVS1H KL9ohSkhRDA5frSfN9H9MSlEcD7CtbrARQrWJOe7AGKNKTfCqTQ7xb41cqzHbkM48isI sidMN+05u47TULm9TzOOEDJcG5UzcI2j9OepAdOWiPEsCYx5V/AeCFhRBFINCo3TMlEk c6joOvdUWXnjSEg+1vtXgu5Zjbc/QwUEnE14zbmOrtoQlPIM62TiKTuK9iaQmoWJQmyu 6hiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6IATeeGJuy9tMvuZpaoaqImJDT16W9mW7DHo+qKzpZ4=; b=Pt1IOfOxu3UAZl7jla9Z/NAbBU8CRrr2OikQVdCgB0Y61zHCYcGq7SAVdzWPmo63Ux mRK8czHgtPsRAOpCx9vow0dgZ1h/nrDxeG2nCvS1nhw4TbgBwtFUNxYyfUpjFHP8k4qS bRYd4CouNIOeAtXFinbBBdgk6+hoxG0NFazQpfJdzJQ2QaFW+f7qqiMhqVquFlJTjSu8 iIOsxxAKQox8dSRLoPfbtqI5hWQLEcjcF2heYrGaWGZ78vhttLMkSRHVYsf1lO5wrPci W7tIKmzCIG3NqyePsWNtbuwAJSqlhO7lIltrSZnWhcBa9K9UlVz//AINFOM06e65/PfQ WdtA== X-Gm-Message-State: ALQs6tClteFLye2QT3Hc37hZ3PFzNfIhQgvqi3405p/ib4R7lqOrGmKs AM/b4V1rkqWp6Mslg7b+CMYgrILxzivpqkLx2p7TGw== X-Google-Smtp-Source: AB8JxZpvZBLiERE74D+7iq6Up6gP8hV7rwaNN1jrPJ1TwRw5TwBTnb75eMqRfkwWi/zq9p+7OflK/CDpYFjQZfRLPHg= X-Received: by 2002:a9d:719a:: with SMTP id o26-v6mr26975912otj.44.1525633302234; Sun, 06 May 2018 12:01:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Sun, 6 May 2018 12:01:01 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72EB51CE@ESESSMB109.ericsson.se> References: <152546246777.11589.13288594519409569524.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B72EB51CE@ESESSMB109.ericsson.se> From: Eric Rescorla Date: Sun, 6 May 2018 12:01:01 -0700 Message-ID: To: Christer Holmberg Cc: The IESG , "hipsec@ietf.org" , "draft-ietf-hip-native-nat-traversal@ietf.org" , "hip-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000099d00056b8e2f5d" Archived-At: Subject: Re: [Hipsec] Eric Rescorla'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 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2018 19:01:44 -0000 --000000000000099d00056b8e2f5d Content-Type: text/plain; charset="UTF-8" On Sun, May 6, 2018 at 10:19 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > I am very familiar with ICE and yet I found this document extremely hard > to follow. The problem is that it cherry-picks pieces > > of ICE and I'm just not sure that it's a complete specification when put > all together. I have noted a number of places where I > > actually am not sure how to implement something, and fixing those will > resolve this DISCUSS, but IMO you really should totally > > rewrite this document either (a) as a variant of ICE or (b) as an > entirely new document not with a pile of new text and then > > references out to ICE sections. > > I haven't been involved in the work on this draft, so I may be wrong, but > I did review the document and my understanding is that RFC 5770 is the > "variant of ICE", and this document is a modification/extension to RFC 5770. > This document is a variant of ICE in the sense that it is ICE-like and explicitly depends on quite a bit of ICE. -Ekr > Regards, > > Christer > > > --000000000000099d00056b8e2f5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, May 6, 2018 at 10:19 AM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:
Hi,

> I am very familiar with ICE and yet I found this document extremely ha= rd to follow. The problem is that it cherry-picks pieces
> of ICE and I'm just not sure that it's a complete specificatio= n when put all together. I have noted a number of places where I
> actually am not sure how to implement something, and fixing those will= resolve this DISCUSS, but IMO you really should totally
> rewrite this document either (a) as a variant of ICE or (b) as an enti= rely new document not with a pile of new text and then
> references out to ICE sections.

I haven't been involved in the work on this draft, so I may be w= rong, but I did review the document and my understanding is that RFC 5770 i= s the "variant of ICE", and this document is a modification/exten= sion to RFC 5770.

This document is a va= riant of ICE in the sense that it is ICE-like and explicitly depends on qui= te a bit of ICE.

-Ekr


Regards,

Christer



--000000000000099d00056b8e2f5d-- From nobody Sun May 6 12:05:52 2018 Return-Path: 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 1B96A12D7F0 for ; Sun, 6 May 2018 12:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 6xYkFg3vZIIb for ; Sun, 6 May 2018 12:05:47 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 F3B4E12D778 for ; Sun, 6 May 2018 12:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525633543; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TpPQVDmzNOxv/rI+W/iarPuk4lBmMs0MvUNI3vDYFsc=; b=Z1Pg/zI0rZ3qHxnUYp04WK72cU0E6FHxA+/R7PmhUXKspIIYlPsvGsBtzbV91lMA NUSoc24QcfWEBzl1QvwlLFe/T3u31+bTP2EjubGr9G8P5pxz5SNjMX2g1Nb3nSAP jOlGsLZ1Cco2dqJhVIy26q1G6FbKWNvglIOuXvpVRG8=; X-AuditID: c1b4fb3a-112a09c00000729c-75-5aef52066797 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A6.E9.29340.6025FEA5; Sun, 6 May 2018 21:05:43 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0382.000; Sun, 6 May 2018 21:05:42 +0200 From: Christer Holmberg To: Eric Rescorla CC: The IESG , "hipsec@ietf.org" , "draft-ietf-hip-native-nat-traversal@ietf.org" , "hip-chairs@ietf.org" Thread-Topic: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT) Thread-Index: AQHT497tPndaPbfR0EuvRo85uzt3DKQi880Q///8FICAACLV2g== Date: Sun, 6 May 2018 19:05:42 +0000 Message-ID: <71503CBD-B852-4D4B-8691-E16356EA9738@ericsson.com> References: <152546246777.11589.13288594519409569524.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B72EB51CE@ESESSMB109.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_71503CBDB8524D4B8691E16356EA9738ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7hC570Psog00dvBbtazqYLVa8Psdu caS1i91i6qLJzBYz/kxkdmD1WLLkJ5PH5MdtzAFMUVw2Kak5mWWpRfp2CVwZc/rvMBc8la84 0vyBqYFxulQXIyeHhICJxLzDMxm7GLk4hASOMEqcbnzJDuEsYpQ4s/oNSxcjBwebgIVE9z9t kAYRAQWJX39OsIDUMAtcZpRo3buJBSQhLFAq8ePPZjaIojKJX79PsELYThLNz9Yyg9gsAioS L/f/B4vzCthLrN5xjwli2XVGiVk7noIVcQoESnQuaAezGQXEJL6fWsMEYjMLiEvcejKfCeJs AYkle84zQ9iiEi8f/2OFqEmW6L/dwQKxQFDi5MwnLBMYhWchaZ+FpGwWkjKIuI7Egt2f2CBs bYllC18zw9hnDjxmQhZfwMi+ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwwg5u+W21g/Hg c8dDjAIcjEo8vPeV30cJsSaWFVfmHmKU4GBWEuHdbg4U4k1JrKxKLcqPLyrNSS0+xCjNwaIk zuuUZhElJJCeWJKanZpakFoEk2Xi4JRqYKzYwKnX7tdjNC/FebpyDlvmzvUfVgu1XPmzhPdl zWstFU7+OC6vqvhPy9fdSU9/FOYg9nd/FO8OzrCl/GGf+b2vmGy/nV99kXVu7eHuO7PXh2i7 5k1tzmSXT608kiERpyD6rTGkx4vB//7qr50T7j5+NGU5w9XTupyHJ4bpzt3GtH2z1k7Wo0os xRmJhlrMRcWJAKwvTJusAgAA Archived-At: Subject: Re: [Hipsec] Eric Rescorla'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 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2018 19:05:49 -0000 --_000_71503CBDB8524D4B8691E16356EA9738ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The question is whether this document should re-define the HIP variations t= o ICE that RFC 5770 already does. Regards, Christer Sent from my iPhone On 6 May 2018, at 22.01, Eric Rescorla > = wrote: On Sun, May 6, 2018 at 10:19 AM, Christer Holmberg > wrote: Hi, > I am very familiar with ICE and yet I found this document extremely hard = to follow. The problem is that it cherry-picks pieces > of ICE and I'm just not sure that it's a complete specification when put = all together. I have noted a number of places where I > actually am not sure how to implement something, and fixing those will re= solve this DISCUSS, but IMO you really should totally > rewrite this document either (a) as a variant of ICE or (b) as an entirel= y new document not with a pile of new text and then > references out to ICE sections. I haven't been involved in the work on this draft, so I may be wrong, but I= did review the document and my understanding is that RFC 5770 is the "vari= ant of ICE", and this document is a modification/extension to RFC 5770. This document is a variant of ICE in the sense that it is ICE-like and expl= icitly depends on quite a bit of ICE. -Ekr Regards, Christer --_000_71503CBDB8524D4B8691E16356EA9738ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,

The question is whether this document should re-define the HIP variati= ons to ICE that RFC 5770 already does.

Regards,

Christer

Sent from my iPhone

On 6 May 2018, at 22.01, Eric Rescorla <= ekr@rtfm.com> wrote:



On Sun, May 6, 2018 at 10:19 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

> I am very familiar with ICE and yet I found this document extremely ha= rd to follow. The problem is that it cherry-picks pieces
> of ICE and I'm just not sure that it's a complete specification when p= ut all together. I have noted a number of places where I
> actually am not sure how to implement something, and fixing those will= resolve this DISCUSS, but IMO you really should totally
> rewrite this document either (a) as a variant of ICE or (b) as an enti= rely new document not with a pile of new text and then
> references out to ICE sections.

I haven't been involved in the work on this draft, so I may be wrong= , but I did review the document and my understanding is that RFC 5770 is th= e "variant of ICE", and this document is a modification/extension= to RFC 5770.

This document is a variant of ICE in the sense that it is ICE-like and= explicitly depends on quite a bit of ICE.

-Ekr


Regards,

Christer



--_000_71503CBDB8524D4B8691E16356EA9738ericssoncom_-- From nobody Sun May 6 12:10:29 2018 Return-Path: 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 D7AD712D77C for ; Sun, 6 May 2018 12:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 KGmi3vEY6m-W for ; Sun, 6 May 2018 12:10:23 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3232A129C59 for ; Sun, 6 May 2018 12:10:21 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id y10-v6so29709886otg.10 for ; Sun, 06 May 2018 12:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fpx5vrEXJM97l1cPHvIc1VNTQ1WWWAEgHqPg+F8a/Zc=; b=qbHmkA4Q0fjGhzduM3wzd4d43NzaRbRY4FKGXq290lhDly+xvNK3loeBY3j3XoR65E BEEZWQZLqPEdUogFwT9wXosNIsFQNrGLloLTXhJq0Xjp+QCDnCoSU7e1EwMqlitn77Jv 0TNk/GDFrvvDxYpBpTEKGQvtJhKnjC2I5no3CKf0+VckWGMrzg/RM8h8VhNOvzG56tYc LmvrjjWupE6O2wEEmaCD0Z/8+XS9czu+oFEKE1NApR11gG6RYjcoe6K+PSyGrkckwM3s DxeOQtLrR0n7faRLqSwTOu2efxx2oCGmEocWU7oLs59UEB8zvWOcqMIkQ0z5zYxkUshQ 2e/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fpx5vrEXJM97l1cPHvIc1VNTQ1WWWAEgHqPg+F8a/Zc=; b=Netjp2KQkDh+cn++gE2n+GjsARbe2ZfpXR2LwIhpGLuDkKuRpD+kwyzwDmPN2KHs+g sArx2ANd0XzazZq/yEo1Ja6vq3w20JbKY7uRqvzabV/ncpdU6sbO7DL8fse2BzlIcAW0 uXWDNxtZeJ1TGnsQlDmYROAn14uZ1ozj0w2VDKX9Z9Nd9xMG609DcEfRc8P5t9oVZNd+ m1LmXti6H25vndu0IUOtWfkQtuK4yyY6aMQ0eo1z5d1VQCVb0OW5g871tAplyB0pQ+OP 2EreHbCLnKAB0SL06KSFrd//rWAOEuWfIyrmvaA4mugrxEiSYE2IwI0unorDi8cZ337p 61+Q== X-Gm-Message-State: ALQs6tB9+ty9kNYn/RsYqSUaSksVMXRQzJiN+BeBX2UlgqM7Kc7wgiGy Uh+7Dw40SKm/s3qBL+KUJhSMZPWJQtaxm6uEFnIDqg== X-Google-Smtp-Source: AB8JxZrS8Y9ImxB6eEQgonIWr0lvxyxyIrENxdlHjP2TP7stbD9UShD9XLFUi9cIHka6BXBxnhvKS6yVWEdQb4RXe7I= X-Received: by 2002:a9d:1055:: with SMTP id o21-v6mr25217115oto.371.1525633820481; Sun, 06 May 2018 12:10:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Sun, 6 May 2018 12:09:40 -0700 (PDT) In-Reply-To: <71503CBD-B852-4D4B-8691-E16356EA9738@ericsson.com> References: <152546246777.11589.13288594519409569524.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B72EB51CE@ESESSMB109.ericsson.se> <71503CBD-B852-4D4B-8691-E16356EA9738@ericsson.com> From: Eric Rescorla Date: Sun, 6 May 2018 12:09:40 -0700 Message-ID: To: Christer Holmberg Cc: The IESG , "hipsec@ietf.org" , "draft-ietf-hip-native-nat-traversal@ietf.org" , "hip-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ed6e58056b8e4d6d" Archived-At: Subject: Re: [Hipsec] Eric Rescorla'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 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2018 19:10:25 -0000 --000000000000ed6e58056b8e4d6d Content-Type: text/plain; charset="UTF-8" On Sun, May 6, 2018 at 12:05 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > The question is whether this document should re-define the HIP variations > to ICE that RFC 5770 already does. > That may be your question, but it's not my question. My question is that I'm not sure this document is sufficiently clear and unambigious to implement, given its current structure. -Ekr > Regards, > > Christer > > Sent from my iPhone > > On 6 May 2018, at 22.01, Eric Rescorla wrote: > > > > On Sun, May 6, 2018 at 10:19 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> > I am very familiar with ICE and yet I found this document extremely >> hard to follow. The problem is that it cherry-picks pieces >> > of ICE and I'm just not sure that it's a complete specification when >> put all together. I have noted a number of places where I >> > actually am not sure how to implement something, and fixing those will >> resolve this DISCUSS, but IMO you really should totally >> > rewrite this document either (a) as a variant of ICE or (b) as an >> entirely new document not with a pile of new text and then >> > references out to ICE sections. >> >> I haven't been involved in the work on this draft, so I may be wrong, but >> I did review the document and my understanding is that RFC 5770 is the >> "variant of ICE", and this document is a modification/extension to RFC 5770. >> > > This document is a variant of ICE in the sense that it is ICE-like and > explicitly depends on quite a bit of ICE. > > -Ekr > > >> Regards, >> >> Christer >> >> >> > --000000000000ed6e58056b8e4d6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, May 6, 2018 at 12:05 PM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:
Hi,

The question is whether this document should re-define the HIP variati= ons to ICE that RFC 5770 already does.

That may be your question, but it's not my question. My questio= n is that I'm not sure this document is sufficiently clear and unambigi= ous to implement, given its current structure.

-Ekr


Regards,

Christer

Sent from my iPhone

On 6 May 2018, at 22.01, Eric Rescorla <ekr@rtfm.com> wrote:



On Sun, May 6, 2018 at 10:19 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

> I am very familiar with ICE and yet I found this document extremely ha= rd to follow. The problem is that it cherry-picks pieces
> of ICE and I'm just not sure that it's a complete specificatio= n when put all together. I have noted a number of places where I
> actually am not sure how to implement something, and fixing those will= resolve this DISCUSS, but IMO you really should totally
> rewrite this document either (a) as a variant of ICE or (b) as an enti= rely new document not with a pile of new text and then
> references out to ICE sections.

I haven't been involved in the work on this draft, so I may be w= rong, but I did review the document and my understanding is that RFC 5770 i= s the "variant of ICE", and this document is a modification/exten= sion to RFC 5770.

This document is a variant of ICE in the sense that it is ICE-like and= explicitly depends on quite a bit of ICE.

-Ekr


Regards,

Christer




--000000000000ed6e58056b8e4d6d-- From nobody Sun May 6 12:23:32 2018 Return-Path: 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 CEFDD129C59 for ; Sun, 6 May 2018 12:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 Om6w9QJ3PM3h for ; Sun, 6 May 2018 12:23:23 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 E3D1D12D77C for ; Sun, 6 May 2018 12:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525634599; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9oaGnZEzBYPXEE8mFjIQ9AuZ5/EmyRTs0VeGhWKrkV8=; b=ZMDyblsrNqJ7J1dzOSgpzjhozj1LCo9BVIdMjmEz5k2OjdO/2UuazMeCN/uKLC9R KIpPdkYhphbevxwTpH/fOUtZVKFMIXAzANRmsq9wW0BCyMRgVb8rmYZA950vrSlo kFBUJEKkNn1rtsBxVEfnQ8eMCByRAl+Zx4YR58NinHE=; X-AuditID: c1b4fb2d-ac3ff700000055bf-66-5aef5627ff7f Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 28.B5.21951.7265FEA5; Sun, 6 May 2018 21:23:19 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0382.000; Sun, 6 May 2018 21:23:19 +0200 From: Christer Holmberg To: Eric Rescorla CC: The IESG , "hipsec@ietf.org" , "draft-ietf-hip-native-nat-traversal@ietf.org" , "hip-chairs@ietf.org" Thread-Topic: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT) Thread-Index: AQHT497tPndaPbfR0EuvRo85uzt3DKQi880Q///8FICAACLV2v//35UAgAAkvtA= Date: Sun, 6 May 2018 19:23:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72EB55E3@ESESSMB109.ericsson.se> References: <152546246777.11589.13288594519409569524.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B72EB51CE@ESESSMB109.ericsson.se> <71503CBD-B852-4D4B-8691-E16356EA9738@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.169] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbFdS1c97H2UwdXlEhbtazqYLVa8Psdu caS1i91i6qLJzBYz/kxkdmD1WLLkJ5PH5MdtzAFMUVw2Kak5mWWpRfp2CVwZD1f+YypoEKo4 /PUwcwPjEcEuRk4OCQETiY1rFrN0MXJxCAkcYZRoX7GVCcJZxCjR8nEXkMPBwSZgIdH9Txuk QURAQeLXnxNgDcwClxklWvduYgFJCAuUSnx6tpUNoqhM4tfvE6wQtp9Ew6t+dpA5LAIqEl/2 ioCEeQV8JW5uWMwIsesak0T/8WNMIAlOgUCJzmVvwWxGATGJ76fWgNnMAuISt57MZ4K4WkBi yZ7zzBC2qMTLx/9YIWwliZPdm1lAdjELaEqs36UP0aooMaX7ITvEXkGJkzOfsExgFJ2FZOos hI5ZSDpmIelYwMiyilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwhg5u+a27g3H1a8dDjAIc jEo8vMIq76OEWBPLiitzDzFKcDArifBuNwcK8aYkVlalFuXHF5XmpBYfYpTmYFES59VbtSdK SCA9sSQ1OzW1ILUIJsvEwSnVwJgwN4zzypUl3vNZ0jyEl3Q92zFDN+5tiNDmjrIZVrcelLOX vFfb/OrhwYIbugmMnGvZFmxcFeQoHLF+TW7TAlWJeb3XN+w8OkmGNVQ86dDG3i+njfPdemZm uegw1TbKuUl/F99yUE/6ySO1oyxJ8+62Gj8R7XU1EpYV4Q2tLjjnY+cYn/5pihJLcUaioRZz UXEiAKyDCcidAgAA Archived-At: Subject: Re: [Hipsec] Eric Rescorla'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 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2018 19:23:25 -0000 SGksDQoNCj4+IFRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoaXMgZG9jdW1lbnQgc2hvdWxkIHJl LWRlZmluZSB0aGUgSElQIHZhcmlhdGlvbnMgdG8gSUNFIHRoYXQgUkZDIDU3NzAgYWxyZWFkeSBk b2VzLg0KPg0KPiBUaGF0IG1heSBiZSB5b3VyIHF1ZXN0aW9uLCBidXQgaXQncyBub3QgbXkgcXVl c3Rpb24uIE15IHF1ZXN0aW9uIGlzIHRoYXQgSSdtIG5vdCBzdXJlIHRoaXMgZG9jdW1lbnQgaXMg DQo+IHN1ZmZpY2llbnRseSBjbGVhciBhbmQgdW5hbWJpZ2lvdXMgdG8gaW1wbGVtZW50LCBnaXZl biBpdHMgY3VycmVudCBzdHJ1Y3R1cmUuDQoNClN1cmUsIHRoZSBtYXkgYmUgZWRpdG9yaWFsIHdv cmsgdG8gZG8sIGJ1dCBJIHN0aWxsIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBjbGFyaWZ5IHdo ZXRoZXIgdGhlIHJlYWRlciBvZiB0aGlzIGRvY3VtZW50IGlzIGV4cGVjdGVkIHRvIGJlIGZhbWls aWFyIHdpdGggUkZDIDU3NzAsIG9yIHdoZXRoZXIgdGhpcyBkb2N1bWVudCBpcyBzdXBwb3NlZCB0 byBiZSBhbiAiSUNFIHZhcmlhbnQiIG9uIGl0cyBvd24uDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCg0KDQoNCk9uIDYgTWF5IDIwMTgsIGF0IDIyLjAxLCBFcmljIFJlc2NvcmxhIDxla3JAcnRm bS5jb20+IHdyb3RlOg0KDQoNCk9uIFN1biwgTWF5IDYsIDIwMTggYXQgMTA6MTkgQU0sIENocmlz dGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KSGks DQoNCj4gSSBhbSB2ZXJ5IGZhbWlsaWFyIHdpdGggSUNFIGFuZCB5ZXQgSSBmb3VuZCB0aGlzIGRv Y3VtZW50IGV4dHJlbWVseSBoYXJkIHRvIGZvbGxvdy4gVGhlIHByb2JsZW0gaXMgdGhhdCBpdCBj aGVycnktcGlja3MgcGllY2VzIA0KPiBvZiBJQ0UgYW5kIEknbSBqdXN0IG5vdCBzdXJlIHRoYXQg aXQncyBhIGNvbXBsZXRlIHNwZWNpZmljYXRpb24gd2hlbiBwdXQgYWxsIHRvZ2V0aGVyLiBJIGhh dmUgbm90ZWQgYSBudW1iZXIgb2YgcGxhY2VzIHdoZXJlIEkgDQo+IGFjdHVhbGx5IGFtIG5vdCBz dXJlIGhvdyB0byBpbXBsZW1lbnQgc29tZXRoaW5nLCBhbmQgZml4aW5nIHRob3NlIHdpbGwgcmVz b2x2ZSB0aGlzIERJU0NVU1MsIGJ1dCBJTU8geW91IHJlYWxseSBzaG91bGQgdG90YWxseSANCj4g cmV3cml0ZSB0aGlzIGRvY3VtZW50IGVpdGhlciAoYSkgYXMgYSB2YXJpYW50IG9mIElDRSBvciAo YikgYXMgYW4gZW50aXJlbHkgbmV3IGRvY3VtZW50IG5vdCB3aXRoIGEgcGlsZSBvZiBuZXcgdGV4 dCBhbmQgdGhlbiANCj4gcmVmZXJlbmNlcyBvdXQgdG8gSUNFIHNlY3Rpb25zLg0KDQpJIGhhdmVu J3QgYmVlbiBpbnZvbHZlZCBpbiB0aGUgd29yayBvbiB0aGlzIGRyYWZ0LCBzbyBJIG1heSBiZSB3 cm9uZywgYnV0IEkgZGlkIHJldmlldyB0aGUgZG9jdW1lbnQgYW5kIG15IHVuZGVyc3RhbmRpbmcg aXMgdGhhdCBSRkMgNTc3MCBpcyB0aGUgInZhcmlhbnQgb2YgSUNFIiwgYW5kIHRoaXMgZG9jdW1l bnQgaXMgYSBtb2RpZmljYXRpb24vZXh0ZW5zaW9uIHRvIFJGQyA1NzcwLg0KDQpUaGlzIGRvY3Vt ZW50IGlzIGEgdmFyaWFudCBvZiBJQ0UgaW4gdGhlIHNlbnNlIHRoYXQgaXQgaXMgSUNFLWxpa2Ug YW5kIGV4cGxpY2l0bHkgZGVwZW5kcyBvbiBxdWl0ZSBhIGJpdCBvZiBJQ0UuDQoNCi1Fa3INCg0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0K From nobody Sun May 6 14:41:07 2018 Return-Path: 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 DB4D512D7F6; Sun, 6 May 2018 14:41:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: hipsec@ietf.org, Gonzalo Camarillo , draft-ietf-hip-rfc4423-bis@ietf.org, gonzalo.camarillo@ericsson.com, hip-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152564286489.26793.2457846656783140871.idtracker@ietfa.amsl.com> Date: Sun, 06 May 2018 14:41:04 -0700 Archived-At: Subject: [Hipsec] Eric Rescorla's No Objection on draft-ietf-hip-rfc4423-bis-19: (with 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2018 21:41:05 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-hip-rfc4423-bis-19: No Objection 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-rfc4423-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3709 Maybe I'm missing something important, but I don't see in this document how you go from a HI (or HIT) to the corresponding IP locator. That seems pretty critical to making this work. Can you point me in the right direction? IMPORTANT S 11.3.1. > avoiding manual configurations. The three components are further > described in the HIP experiment report [RFC6538]. > > Based on the interviews, Levae et al suggest further directions to > facilitate HIP deployment. Transitioning the HIP specifications to > the standards track may help, but other measures could be taken. As This confuses me, because we seem to be looking to advance some of the HIP specs (e.g., hip-dex) at PS COMMENTS S 3.1. > were obtained. For 64 bits, this number is roughly 4 billion. A > hash size of 64 bits may be too small to avoid collisions in a > large population; for example, there is a 1% chance of collision > in a population of 640M. For 100 bits (or more), we would not > expect a collision until approximately 2**50 (1 quadrillion) > hashes were generated. It's not just a matter of collisions being hard, but also of being difficult to produce an HI with a given name. S 4. > 'well known', some unpublished or 'anonymous'. A system may self- > assert its own identity, or may use a third-party authenticator like > DNSSEC [RFC2535], PGP, or X.509 to 'notarize' the identity assertion > to another namespace. It is expected that the Host Identifiers will > initially be authenticated with DNSSEC and that all implementations > will support DNSSEC as a minimal baseline. This wasn't a very good assumption when 4423 was published, and it seems even worse now, given the low rate of deployment of DNSSEC and the fact that we know many middleboxes break DNSSEC. S 4.3. > packet. Consequently, a HIT should be unique in the whole IP > universe as long as it is being used. In the extremely rare case of > a single HIT mapping to more than one Host Identity, the Host > Identifiers (public keys) will make the final difference. If there > is more than one public key for a given node, the HIT acts as a hint > for the correct public key to use. How do you handle second-preimage attacks on the hash? S 5.1. > At the server side, utilizing DNS is a better alternative than a > shared Host Identity to implement load balancing. A single FQDN > entry can be configured to refer to multiple Host Identities. Each > of the FQDN entries can be associated with the related locators, or a > single shared locator in the case the servers are using the same HIP > rendezvous server Section 6.3 or HIP relay server Section 6.4. This is becoming a less common practice. How do you handle anycast, which is the modern practice? S 7. > > The encapsulation format for the data plane used for carrying the > application-layer traffic can be dynamically negotiated during the > key exchange. For instance, HICCUPS extensions [RFC6078] define one > way to transport application-layer datagrams directly over the HIP > control plane, protected by asymmetric key cryptography. Also, S-RTP Nit: SRTP, no hyphen From nobody Mon May 7 06:42:41 2018 Return-Path: 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 3D954120227; Mon, 7 May 2018 06:42:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-hip-rfc4423-bis@ietf.org, Gonzalo Camarillo , hip-chairs@ietf.org, gonzalo.camarillo@ericsson.com, hipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152570055924.1427.16939102336092145446.idtracker@ietfa.amsl.com> Date: Mon, 07 May 2018 06:42:39 -0700 Archived-At: Subject: [Hipsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-hip-rfc4423-bis-19=3A_=28with_COMMENT=29?= 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 13:42:39 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-hip-rfc4423-bis-19: No Objection 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-rfc4423-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few minor high-level comments/questions: 1) To me it feels that sec 11 doesn't really belong in this bis doc. Maybe that is rather an own report or can just go in the appendix? 2) Should this document maybe discuss connection migration as used by QUIC as an alternative (based on short term connection identifiers instead of course)? Background: to provide identities between two endpoints, I'd say that TLS is sufficient or even the more appropriate solution. However, this document does not talk very much about cases where the identify of other IP hosts (not endpoints) is important. Oft course it covers the mobility use case but that also seems less relevant with migration support in QUIC. From nobody Wed May 9 08:02:50 2018 Return-Path: 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 7AC711242F5; Wed, 9 May 2018 08:02:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-hip-native-nat-traversal@ietf.org, Gonzalo Camarillo , 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: <152587816145.3957.17385929656409014655.idtracker@ietfa.amsl.com> Date: Wed, 09 May 2018 08:02:41 -0700 Archived-At: Subject: [Hipsec] Benjamin Kaduk's No Objection on draft-ietf-hip-native-nat-traversal-28: (with 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 15:02:41 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-hip-native-nat-traversal-28: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document does a poor job at convincing me that there is a need to re-specify ICE for use in HIP contexts as opposed to just using ICE directly, up until Appendix B. I'd suggest moving some of the key points into at least the Introduction and arguably the Abstract as well, to make it clear that this is not just needless duplication for ideological purity. I think there's some lingering terminology confusion (as a result of needing to align the new bits in Native HIP-ICE with those retained from RFC 5077, along with the move from 5245 to 5245bis. Specifically, while it's fine for this document to refer to "ICE offer" and "ICE answer", 5245bis itself does not talk of "offer" and "answer", which are now concepts only in SDP, IIUC. Things also seem a bit hazy about server reflexive vs. server relay candidates (though maybe here the confusion is just on my end) -- in regular ICE, a server reflexive candidate is obtained by a STUN client making a one-shot request of a STUN server to find out what address is being used on the other side of a NAT, and doesn't require any state on the STUN server. But in this document we have a SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED Notify/error packet that implies that state is needed on the Data Relay Server for a reflexive candidate, text about "when the relay service is split between hosts, the server reflexive candidate [from Control SHOULD be used over the one from Data]", and also other discussion about needing to register new reflexive candidates to avoid collisions or in potential multihoming future work. Some section-by-section comments follow. Section 2 Responder: The Responder is the host that receives the I1 packet from the Initiator. Does this still hold if the message is misdelivered or an attacker is in the network? Section 3 [...] At this point, also the HIP signaling can be sent over the same address/port pair, and is demultiplexed from IPsec as described in the UDP encapsulation standard for IPsec [RFC3948]. "demultiplex" does not appear anywhere in RFC 3948; it might be worth using a few more words here to clarify what is going on. Section 4.1 A Control Relay Server MUST silently drop packets to a Control Relay Client that has not previously registered with the HIP relay. How does the relay know where they are targetted without the registration information? This applies both renewals of service registration but also to host movement, where especially the latter requires the Control Relay Client to learn its new server reflexive address candidate. This is kind of awkward wording; maybe: This applies to both renewals of service registration and to host movement. It is especially important for the case of host movement, as this is the mechanism that allows the Control Relay Client to learn its new server reflexive address candidate. Section 4.2 [...] A host SHOULD employ only a single server for gathering the candidates for a single HIP association; either one server providing both Control and Data Relay Server functionality, or one Control Relay Server and also Data Relay Server if the functionality is offered by another server. The second half of this sentence seems to contradict the SHOULD, so probably some rewording is in order. [...] If a relayed candidate is identical to a host candidate, the relayed candidate must be discarded. NAT64 considerations in [I-D.ietf-ice-rfc5245bis] apply as well. I don't think this has enough detail of reference to ICE -- a relayed candidate being identical to a host candidate is, IIUC, quite unexpected. This is even noted in 5245bis, at the bottom of page 20 (of the -20). Unlike ICE, this protocol only creates a single UDP flow between the two communicating hosts, so only a single component exists. Hence, the component ID value MUST always be set to 1. ICE or SDP? Section 4.5 In step 2, the Control Relay Server receives the I1 packet. If the destination HIT belongs to a registered Responder, the Control Relay Server processes the packet. Do HIP participants register specifically as Responder/Initiator, or is this just that the entity that is Responder in this exchange, has registered at the Control Relay Server? [...] The RELAY_TO parameter is not integrity protected by the signature of the R1 to allow pre-created R1 packets at the Responder. This seems to allow an attacker to replay R1 packets and have the Relay transmit them to the Initiator. Are there cases where this presents an increase in attacker capabilities (e.g., when the Relay is allowed to send to the Initiator but the attacker is not)? (When would such pre-created R1 packets be useful?) Should step 7 explicitly duplicate the "validate REPLAY_HMAC" part of step 3? Section 4.6 The situation with the (non-)existence of aggressive nomination between 5245bis and MMUSIC-ICE probably merits further investigation. (That is, it may not be necessary to mention explicitly that regular nomination is used.) The Initiator MUST take the role of controlling host and the Responder acts as the controlled host. The roles MUST persist throughout the HIP associate lifetime (to be reused in the possibly mobility UPDATE procedures). In the case both communicating nodes are initiating the communications to each other using an I1 packet, the conflict is resolved as defined in section 6.7 in [RFC7401]: the host with the "larger" HIT changes to its Role to Responder. In such a case, the host changing its role to Responder MUST also switch to controlling role. The last clause seems to not match the earlier text about the Initiator being the controlling role. Section 4.6.1 In step 2, the Initiator sends a connectivity check, using the same address pair candidate as in the previous step, and the message traverses successfully the NAT boxes. The message includes the same parameters as in the previous step. It should be noted that the sequence identifier is locally assigned by the Responder, so it can be different than in the previous step. Step 2 is from Initiator to Responder, and the message in step 1 got dropped, so I'm quite confused at how the sequence identifier in step 2 could be assigned by the Responder as opposed to the Initiator. Step 4 could say whether the sequence number from step 1 is reused or a new one is allocated for the retransmission (even though it is clarified later as "SHOULD be sent with the same sequence identifier"). Section 4.7.2 [...] However, the Responder SHOULD NOT send any ESP to the Initiator's address before it has received data from the Initiator, as specified in Sections 4.4.3. and 6.9 of [RFC7401] and in Sections 3.2.9 and 5.4 of [RFC8046]. I don't see a Section 3.2.9 in RFC 8046. Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected MUST NOT be sent via a Control Relay Server, the Responder SHOULD reject such I2 packets and reply with a NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY packet (see Section 5.10). How does this mesh with a few paragraphs back, when the Responder MUST include the address it got by registering at a Control Relay Server in its R1 (only when it is including UDP-ENCAPSULATION NAT as one of its supported modes)? Section 4.7.3 [...] The Initiator may receive multiple R1 packets, with and without UDP encapsulation, from the Responder. However, after receiving a valid R1 and answering it with an I2, further R1 packets that are not retransmissions of the original R1 message MUST be ignored. We just said there may be multiple, so which one is "the" original R1 message? Should Section 4.8 repeat the earlier admonitions against a Relay Server forwarding traffic that does not involve a Client that has egistered with that Relay Server? Section 4.9 The relay still has to apply RELAY_HMAC; that's just not currently shown in the diagram, right? Section 5.6 The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is shown in Figure 10. All parameters are identical except for the type. REG_FROM is the only parameter covered with the signature. I suggest "Of the three, only REG_FROM is covered by the signature." Section 6.1 The RFC 5770 text talks about TURN servers, but that's no longer applicable in this document (instead, Data Relay Servers are used to relay data in a similar usage). Also, the protection against DoS described in the last paragraph seems to only be partial protection, since incoming connections can still be affected by DoS, but outgoing ones are still possible. Section 6.2 This is the first mention of Opportunistic Mode at all in the document; it might be nice to refer to the section of 7401 where it's documented. Section 6.6 Is the invalid list of candidates sent *for* its peer or *to* its peer? Appendix B o Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP protocol in order to avoid middlebox tampering. This reads a bit oddly. Just to check: we don't need to do the XORing in Native ICE-HIP because the addresses are covered by an HMAC and the "tampering" wouldn't work? If so I'd suggest: o In ICE, addresses being conveyed across a NAT are XOR-ed to prevent middlebox tampering. Native ICE-HIP does not need to use XOR because such tampering is prevented at the HIP layer. From nobody Wed May 9 08:39:29 2018 Return-Path: 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 78C5F12D880; Wed, 9 May 2018 08:39:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-hip-native-nat-traversal@ietf.org, Gonzalo Camarillo , 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: <152588036744.3925.12181216798778417370.idtracker@ietfa.amsl.com> Date: Wed, 09 May 2018 08:39:27 -0700 Archived-At: Subject: [Hipsec] Alissa Cooper's No Objection on draft-ietf-hip-native-nat-traversal-28: (with 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 15:39:27 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-hip-native-nat-traversal-28: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I admit to not having much familiarity with HIP, so apologies if some of these questions seem off-base. Why is this document on the standards track when RFC 5770 was experimental? Section 6.1 says: "The locators are in plain text format in favor of inspection at HIP- aware middleboxes in the future. The current document does not specify encrypted versions of LOCATOR_SETs, even though it could be beneficial for privacy reasons to avoid disclosing them to middleboxes." This seems to cut in the opposite direction of some of the other work we have going on in the IETF, where the justification for maintaining header information in the clear is for backwards-compatability with existing middleboxes, not to facilitate some to-be-developed middlebox behavior. Why is this justified for HIP? Section 6.1 also says "an end-host may exclude certain host addresses from its LOCATOR_SET parameter," but I don't think this is totally clear in Section 4.5 where it talks about "all the HIP candidates." I also wonder if it would be possible to provide some guidance about the circumstances under which an initiator might choose to exclude certain addresses, e.g. if there is a common deployment scenario where it's clear that certain candidates are meant to remain private. Nits: = Section 1 = " As one solution, the HIP experiment report [RFC6538] mentions that Teredo based NAT traversal for HIP and related ESP traffic (with double tunneling overhead)." This is a sentence fragment. = Section 2 = The paragraph about RFC2119 should also reference RFC8174. From nobody Wed May 9 08:40:27 2018 Return-Path: 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 EF20B12D880; Wed, 9 May 2018 08:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=n0k8XRIq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VQaQ/0B5 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 S6cVXbCxJ73e; Wed, 9 May 2018 08:40:23 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4123F12D886; Wed, 9 May 2018 08:40:23 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 73E09213AD; Wed, 9 May 2018 11:40:22 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 09 May 2018 11:40:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=eeztYLqW2jHqaBKHeXepwgEX6AfF/70KWH930MAppNw=; b=n0k8XRIq eO0nGQucKUCy9Hegp/evhPQn8xas7qqe55ccqvX3n+hYpIWvMvUJHwQWK4K6ye/S dtUSe22tlJCNGCRlRIYR4V1BvSjwXhKlSgG8bg06MT7P7Cvgxps8ZH+D8gGvkycV T+sad1MLSugm1QX8r0tu+EQICPNKahRF9n1TtWbJtbDLjIvF+JjBnWmVyOdIXytE VDQQ9X4nI2kIRtBs2lkPQzRQ20aqmYL9g2KpZBu3k/hhHdavnr/up8NnQ2le/7S0 FEDWB2JahSzTvEVH27PEpqS/Ct2na8dhPdSo/gKJ7hjDvfrkiPQN9rRPYy6edh/t v2VZAn9OCFXtoQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=eeztYLqW2jHqaBKHeXepwgEX6AfF/ 70KWH930MAppNw=; b=VQaQ/0B54dlN1Yw0G86fxQ5RWbUfZrD5qPZkkdqgEqE2U ShS9RTl36yfw+4W/YyFy+4PWZOA96pyeHwZ7hn+CQtQwNJBUIjtu/CTUoyfOC41/ w2uuuvVyyMRsLIW6YJQG4RvQ2QixO/Wm07wA9Rdp9pDmygBTKzF56fx9U620dw4c V5qKks2N8LclkKbpAyQGLVvjnCPmGVKGBTVCxGb6jIdTA8j9hQxNBgm/etmRp9+H 61wcTLlmCLMdd4BNLc71QhcFEIWZD0Pko9yNx+RWH1/uYlZhdAiZz+NKEg2tqvpP GGR2wmC20giStFubODcjLg+6OuQjIK4XyEu1z07fA== X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.81]) by mail.messagingengine.com (Postfix) with ESMTPA id 92F4D10260; Wed, 9 May 2018 11:40:21 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0EA69603-6D17-48DC-A7C8-4A59E210CCAD" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <1e94caf7-9b00-7cea-e3b4-0922c0cb3942@ericsson.com> Date: Wed, 9 May 2018 11:40:20 -0400 Cc: Roni Even , IETF Gen-ART , hipsec@ietf.org, draft-ietf-hip-native-nat-traversal.all@ietf.org Message-Id: <0CB6276E-7825-413F-8F70-D47FF1144C69@cooperw.in> References: <152317272632.1526.14567136074332180513@ietfa.amsl.com> <1e94caf7-9b00-7cea-e3b4-0922c0cb3942@ericsson.com> To: Miika Komu X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Hipsec] [Gen-art] Genart telechat review of draft-ietf-hip-native-nat-traversal-28 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 15:40:25 -0000 --Apple-Mail=_0EA69603-6D17-48DC-A7C8-4A59E210CCAD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Roni, thanks for your review. Miika, thanks for your response. I have = entered a No Objection ballot. Alissa > On Apr 9, 2018, at 8:05 AM, Miika Komu = wrote: >=20 > Hi Roni, >=20 > On 04/08/2018 10:32 AM, Roni Even wrote: >> Reviewer: Roni Even >> Review result: Ready with Nits >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please wait for direction from your >> document shepherd or AD before posting a new version of the draft. >> For more information, please see the FAQ at >> . >> Document: draft-ietf-hip-native-nat-traversal-?? >> Reviewer: Roni Even >> Review Date: 2018-04-08 >> IETF LC End Date: 2018-02-26 >> IESG Telechat date: 2018-05-10 >> Summary: >> The document is ready for publication as a standard track RFC with = one nit. >> Major issues: >> Minor issues: >> Nits/editorial comments: >> In section 7 - "a new error type = SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED >> in Section 5.9." It is in section 5.10 >=20 > good catch, I'll fix the reference in the next version. Thanks! >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art = --Apple-Mail=_0EA69603-6D17-48DC-A7C8-4A59E210CCAD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Roni, thanks for your review. Miika, thanks = for your response. I have entered a No Objection ballot.

Alissa

On = Apr 9, 2018, at 8:05 AM, Miika Komu <miika.komu@ericsson.com> wrote:

Hi Roni,

On 04/08/2018 10:32 AM, Roni Even = wrote:
Reviewer: = Roni Even
Review result: Ready with Nits
I = am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being = processed
by the IESG for the IETF Chair. Please wait for = direction from your
document shepherd or AD before posting = a new version of the draft.
For more information, please = see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-hip-native-nat-traversal-??
Reviewer: Roni Even
Review Date: 2018-04-08
IETF LC End Date: 2018-02-26
IESG Telechat = date: 2018-05-10
Summary:
The document is = ready for publication as a standard track RFC with one nit.
Major issues:
Minor issues:
Nits/editorial comments:
In section 7 - "a new = error type  SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED
in Section 5.9." It is in section 5.10

good catch, I'll fix the reference in the next = version. Thanks!

_______________________________________________
Gen-art mailing = list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_0EA69603-6D17-48DC-A7C8-4A59E210CCAD-- From nobody Wed May 9 13:44:19 2018 Return-Path: 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 EF02B126DEE; Wed, 9 May 2018 13:44:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-hip-native-nat-traversal@ietf.org, Gonzalo Camarillo , 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: <152589865293.3917.7159266545812424892.idtracker@ietfa.amsl.com> Date: Wed, 09 May 2018 13:44:12 -0700 Archived-At: Subject: [Hipsec] Alvaro Retana's No Objection on draft-ietf-hip-native-nat-traversal-28: (with 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 20:44:13 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-hip-native-nat-traversal-28: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Like Benjamin, I also found the relationship between this document and ICE somewhat confusing until the very end (Appendix B). The attempt to "follow ICE methodology but reuse HIP messaging format to achieve the same functionality" results in lack of clarity, so I also agree with Eric's opinion that a rewrite would help, and support his DISCUSS. From nobody Wed May 9 13:58:33 2018 Return-Path: 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 E6A7E129BBF; Wed, 9 May 2018 13:58:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-hip-rfc4423-bis@ietf.org, Gonzalo Camarillo , 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: <152589950593.3860.2313922344171073216.idtracker@ietfa.amsl.com> Date: Wed, 09 May 2018 13:58:25 -0700 Archived-At: Subject: [Hipsec] Benjamin Kaduk's No Objection on draft-ietf-hip-rfc4423-bis-19: (with 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 20:58:26 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-hip-rfc4423-bis-19: No Objection 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-rfc4423-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share Eric's concerns about the need for second-preimage-resistance from the hash, and in particular with the birthday bound, it's unclear that using a 128-bit hash leaves a very large margin for growth. Some other section-by-section notes follow. Section 1 [...] HIP provides for limited forms of trust between systems, enhance mobility, multi-homing and dynamic IP renumbering, aid in protocol translation / transition, and reduce certain types of denial-of-service (DoS) attacks. I think that something is weird here with singular vs. plural in the list elements. Section 4 I agree with the secdir reviewer's not about "SHOULD NOT [implement non-cryptographic HIP]" Section 5.1 At the client side, a host may have multiple Host Identities, for instance, for privacy purposes. Another reason can be that the person utilizing the host employs different identities for different administrative domains as an extra security measure. If a HIP-aware middlebox, such as a HIP-based firewall, is on the path between the client and server, the user or the underlying system should carefully choose the correct identity to avoid the firewall to unnecessarily drop HIP-based connectivity [komu-diss]. In addition to the firewall case, choosing the correct identifier can also impact the privacy considerations, as a given identifier would be trackable by on-path entities. Section 6.2 When a node moves while communication is already on-going, address changes are rather straightforward. The peer of the mobile node can just accept a HIP or an integrity protected ESP packet from any address and ignore the source address. However, as discussed in Section 12.2 below, a mobile node must send a HIP UPDATE packet to inform the peer of the new address(es), and the peer must verify that the mobile node is reachable through these addresses. Am I reading this right that from a technical perspective, the peer can just accept stuff from wherever, but from a policy/protocol perspective the UPDATE requirement is included? The text could probably be a bit more clear, potentially even without using RFC 2119 language. Section 10 There are a number of variables that influence the HIP exchange that each host must support. All HIP implementations should support at least 2 HIs, one to publish in DNS or similar directory service and an unpublished one for anonymous usage. Although unpublished HIs I suggest a parenthetical that the unpublished one should expect to be rotated frequently in order to disrupt linkability/trackability. will be rarely used as responder HIs, they are likely to be common for initiators. Support for multiple HIs is recommended. [...] If multiple means "more than two", it's probably better to say that. (If multiple means "more than one", this is just a weaker version of "should support at least 2", above.) And it's rather tempting to make it a MUST, anyway. Many initiators would want to use a different HI for different responders. The implementations should provide for a policy mapping of initiator HITs to responder HITs. This policy should also include preferred transforms and local lifetimes. "mapping of initiator to responder" is potentially confusing, in that in practice the procedure will be "I want to talk to responder A, so let me look up that I use HIT X to talk to responder A", which is the opposite direction from this text. Section 11.1 I'd consider replacing "is an attempt to" with "attempts to" -- for example, IPv6 tries to do a lot of things in addition to killing NAT! Section 11.3.1 [...]Second, a data plane component is needed. Most HIP implementations utilize the so called BEET mode of ESP that has been available since Linux kernel 2.6.27, but is included also as a userspace component in a few of the implementations. Nit: "but ESP is included", I think. Section 12.1 I don't understand the usage of "a-priori" in: The need to support multiple hashes for generating the HIT from the HI affords the MitM to mount a potentially powerful downgrade attack due to the a-priori need of the HIT in the HIP base exchange. In HIP, the Security Association for ESP is indexed by the SPI; the source address is always ignored, and the destination address may be ignored as well. Therefore, HIP-enabled Encapsulated Security Payload (ESP) is IP address independent. This might seem to make attacking easier, but ESP with replay protection is already as well protected as possible, and the removal of the IP address as a check should not increase the exposure of ESP to DoS attacks. It seems like there's still some potential incrased exposure, as validating the ESP crypto is presumably more expensive than validating source/destination IP addresses. Section 12.3 [...] At middleboxes, HIP-aware firewalls [lindqvist-enterprise] can use HITs or public keys to control both ingress and egress access to networks or individual hosts, even in the presence of mobile devices because the HITs and public keys are topologically independent. [...] Nit: I think that just "topology independent" is what's intended. From nobody Wed May 9 14:21:58 2018 Return-Path: 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 EEB80129C56 for ; Wed, 9 May 2018 14:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 x6IHlgxJ4lSy for ; Wed, 9 May 2018 14:21:52 -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 A32C612DA6C for ; Wed, 9 May 2018 14:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525900909; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0vY9zTfrgxvRpXvMJPvZSsqOCOnVu1DOYlXUm0PHQiI=; b=LDcYKUu20fRenHCnMus3ujRdyQhA8ZEg/D9wmAVYTqYcKpDzcnCWaQ+EJMlvVZM3 hL2/j5+h3l8XNNNc4zFLYtUhxWcnKxvz/U2RzqSTmk3WSe6COZla0Ib55CM7cbvK xtzs7yl+LCQpoDqkvmNO4i8okg4aPTHVPlfR09MH+Cw=; X-AuditID: c1b4fb30-2a5ff70000006e0c-3f-5af3666d0f2c Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 19.A4.28172.D6663FA5; Wed, 9 May 2018 23:21:49 +0200 (CEST) Received: from [100.94.2.4] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.382.0; Wed, 9 May 2018 23:21:48 +0200 To: Christer Holmberg , Eric Rescorla CC: The IESG , "hipsec@ietf.org" , "draft-ietf-hip-native-nat-traversal@ietf.org" , "hip-chairs@ietf.org" References: <152546246777.11589.13288594519409569524.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B72EB51CE@ESESSMB109.ericsson.se> <71503CBD-B852-4D4B-8691-E16356EA9738@ericsson.com> <7594FB04B1934943A5C02806D1A2204B72EB55E3@ESESSMB109.ericsson.se> From: Miika Komu Organization: Ericsson AB Message-ID: <7e581670-9410-e46c-0fb5-dd00e9932778@ericsson.com> Date: Thu, 10 May 2018 00:21:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72EB55E3@ESESSMB109.ericsson.se> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM2K7qG5u2ucog76pQhbtazqYLVa8Psdu caS1i91i6qLJzBYz/kxkdmD1WLLkJ5PH5MdtzAFMUVw2Kak5mWWpRfp2CVwZtzb9Zyp4K1Tx aOUuxgbGp3xdjJwcEgImEt+b5zF3MXJxCAkcYZTY8msGC4SznFHixbXzjCBVwgKlEj/+bGbr YuTgEBEIk7i2mQukhlngMqNE695NUA2zmCWm7D3GDNLAJqAlserOdTCbX0BSYkPDbjCbV8Be YsGZS2wgNouAqsTW/h2sILaoQITEvfOf2CBqBCVOznzCArKMU8BPYnNfAkiYWcBCYuZ8iHuY BcQlbj2ZzwRhy0tsfzuHGaRcSEBF4uKx4AmMQrOQDJqFpHsWku5ZSLoXMLKsYhQtTi1Oyk03 MtJLLcpMLi7Oz9PLSy3ZxAgM/oNbfhvsYHz53PEQowAHoxIPr7vH5ygh1sSy4srcQ4wSHMxK IryP44FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeS38NkcJCaQnlqRmp6YWpBbBZJk4OKUaGJdN 7Ml8UGIl22IU+ZP/gvB15u0Fx/ruLPDyvv1YvvyYZfCud6wJjzTytAo2Ghhaak81fG5upl44 43Nf3lKxNf+6FdN+va5Ta7o+7RODL/PCk87OD+dvOrSfh0dhkp/b5TYjQ/7Vm3tXzTw0bQeL 9aO4FQueahWsaOkSs8xsWzXpkfHm+iX3HJRYijMSDbWYi4oTAd2dAXl6AgAA Archived-At: Subject: Re: [Hipsec] Eric Rescorla'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 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 21:21:54 -0000 Hi, On 05/06/2018 10:23 PM, Christer Holmberg wrote: > Hi, > >>> The question is whether this document should re-define the HIP variations to ICE that RFC 5770 already does. >> >> That may be your question, but it's not my question. My question is that I'm not sure this document is >> sufficiently clear and unambigious to implement, given its current structure. > > Sure, the may be editorial work to do, but I still think it is important to clarify whether the reader of this document is expected to be familiar with RFC 5770, or whether this document is supposed to be an "ICE variant" on its own. we wanted to keep the same document structure as RFC5770 because the developers were already familiar with it (and has two interoperable implementations). While we tried to duplicate some RFC5770 material to make the specification a bit more standalone, the document is still aimed for people who developed RFC5770. As you noted, the document is missing the exact section references because the ICE spec has been a moving target but I guess the references would safe to be fixed now. Thanks Eric for the insightful technical comments. I'll try to get you answers as soon as possible. > Regards, > > Christer > > > > > On 6 May 2018, at 22.01, Eric Rescorla wrote: > > > On Sun, May 6, 2018 at 10:19 AM, Christer Holmberg wrote: > Hi, > >> I am very familiar with ICE and yet I found this document extremely hard to follow. The problem is that it cherry-picks pieces >> of ICE and I'm just not sure that it's a complete specification when put all together. I have noted a number of places where I >> actually am not sure how to implement something, and fixing those will resolve this DISCUSS, but IMO you really should totally >> rewrite this document either (a) as a variant of ICE or (b) as an entirely new document not with a pile of new text and then >> references out to ICE sections. > > I haven't been involved in the work on this draft, so I may be wrong, but I did review the document and my understanding is that RFC 5770 is the "variant of ICE", and this document is a modification/extension to RFC 5770. > > This document is a variant of ICE in the sense that it is ICE-like and explicitly depends on quite a bit of ICE. > > -Ekr > > > Regards, > > Christer > > > From nobody Wed May 9 16:34:24 2018 Return-Path: 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 67FA012DA17; Wed, 9 May 2018 16:34:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-hip-rfc4423-bis@ietf.org, Gonzalo Camarillo , 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: <152590886238.10463.9438651181532889998.idtracker@ietfa.amsl.com> Date: Wed, 09 May 2018 16:34:22 -0700 Archived-At: Subject: [Hipsec] Adam Roach's No Objection on draft-ietf-hip-rfc4423-bis-19: (with 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 23:34:22 -0000 Adam Roach has entered the following ballot position for draft-ietf-hip-rfc4423-bis-19: No Objection 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-rfc4423-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for everyone's work on updating RFC 4423. In general, I agree with Mirja's point that section 11 seems a bit disjoint from the rest of the document, and would be better served as an appendix. It's also somewhat jarring to have a document whose abstract talks about a "new namespace" and a "new protocol layer," which goes on to describe conclusions from twelve years of deployment experience. I would recommend re-working all uses of the word "new" (which, in most cases, can be achieved by either removing the word "new" from sentences, or replacing it with "HIP"). The remainder of my comments are editorial nits. --------------------------------------------------------------------------- §2.1: > +---------------+---------------------------------------------------+ > | Term | Explanation | > +---------------+---------------------------------------------------+ > | Public key | The public key of an asymmetric cryptographic key | > | | pair. Used as a publicly known identifier for | > | | cryptographic identity authentication. Public is | > | | a a relative term here, ranging from "known to | > | | peers only" to "known to the world." | Nit: this text contains a doubled "a" ("...a a relative..."). --------------------------------------------------------------------------- §2.2: Nit: The change in spacing in this table makes certain terms difficult to read (e.g., "HIP base exchange HIP packet" appears to be a single term until the table is closely examined.) Consider reverting to the spacing from RFC 4423. --------------------------------------------------------------------------- §3.1: > o The names should have a fixed length representation, for easy Nit: "fixed-length" is a compound adjective, and should be hyphenated. cf. https://www.google.com/search?q=compound+adjective > (e.g the TCB). Nit: The conventional form would call for "(e.g., the TCB)" cf. https://www.google.com/search?q="e.g."+punctuation+comma > o The names should be long lived, but replaceable at any time. This "long-lived" > designed, it can deliver all of the above stated requirements. "above-stated" --------------------------------------------------------------------------- §4: > In theory, any name that can claim to be 'statistically globally > unique' may serve as a Host Identifier. In the HIP architecture, the > public key of a private-public key pair has been chosen as the Host > Identifier because it can be self managed and it is computationally "self-managed" --------------------------------------------------------------------------- §6.5: > The control plane between two hosts is terminated using a secure two > message exchange as specified in base exchange specification "two-message" --------------------------------------------------------------------------- §7: > control plane, protected by asymmetric key cryptography. Also, S-RTP > has been considered as the data encapsulation protocol [hip-srtp]. "SRTP" rather than "S-RTP". --------------------------------------------------------------------------- §8: > Besides this "native" NAT traversal mode for HIP, other NAT traversal > mechanisms have been successfully utilized, such as Teredo > [varjonen-split]. Please cite RFC 4380 for "Teredo." e.g.: Besides this "native" NAT traversal mode for HIP, other NAT traversal mechanisms have been successfully utilized, such as Teredo [RFC4380], as described in [varjonen-split]. --------------------------------------------------------------------------- §8: > can map to a single IP address on a NAT, simplifying connections on > address poor NAT interfaces. The NAT can gain much of its knowledge "address-poor" --------------------------------------------------------------------------- §11.1: > Considering such human errors, a site > employing location-independent identifiers as promoted by HIP may > experience less problems while renumbering their network. "...experience fewer problems..." > o HITs (or LSIs) can be used in IP-based access control lists as a > more secure replacement for IPv6 addresses. Besides security, HIT > based access control has two other benefits. "HIT-based" > environments. For instance, the benefits of HIT based access "HIT-based" --------------------------------------------------------------------------- §11.2: > The key exchange introduces some extra latency (two round trips) in > the initial transport layer connection establishment between two "transport-layer" > keys and Diffie-Hellman key derivation at the control plane, but this > occurs only during the key exchange, its maintenance (handoffs, > refreshing of key material) and tear down procedures of HIP "tear-down" --------------------------------------------------------------------------- §11.3.1: > Networks [henderson-vpls] to facilitate, e.g, supervisory control and "e.g.," --------------------------------------------------------------------------- §11.4: > A HI is a cryptographic public key. However, instead of using > the keys directly, most protocols use a fixed size hash of the > public key. "fixed-size" > HIP provides both stable and temporary Host Identifiers. > Stable HIs are typically long lived, with a lifetime of years "long-lived" > network services. Additionally, the Host Identifiers, as > public keys, are used in the built in key agreement protocol, "built-in" > HIP reduces dependency on IP addresses, making the so called "so-called" --------------------------------------------------------------------------- §12.1: > Other types of MitM attacks against HIP can be mounted using ICMP > messages that can be used to signal about problems. As a overall "...an overall..." > be aborted after some retries). As a drawback, this leads to an > 6-way base exchange which may seem bad at first. However, since this "...a 6-way..." From nobody Wed May 9 18:15:28 2018 Return-Path: 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 DB7B912D810; Wed, 9 May 2018 18:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=JCu+XQlM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NeCyHK25 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 U7Evr2KLkoCo; Wed, 9 May 2018 18:15:25 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3516112E858; Wed, 9 May 2018 18:15:25 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 64D4422029; Wed, 9 May 2018 21:15:24 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 09 May 2018 21:15:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=q0BInCHRp5e4CdY5Mq2V5V+oTDhPe SE4UmGO4DxfM7I=; b=JCu+XQlMFxiSPzseK9eZ3bkTl7ckvVd04MgbMQObfxxfg bphlmiYawySIaCwFyoTP+Euf5cfbkLDdkn1pqHwREW27wPdO9JaCUULmnRsRjy4l Xj9G/B/JA6PCt6ZF7ZR70Dr9HRRmtv3N064uMvs2akOz6NhqTXKsN7O9Kge+U8vS +N4faadb9vnZDtXYsrXpdJkvtYiirl9C0/QPPKJvYpc70WANrKSMXivaEp+HpyC0 n6mgYEIq4zyGkbiLZbTclTgvP4xrPgtQZr3o9OsJ5fUwF+A3cXLGLns9cc2T2tnx QuNRUZUYx/wiji+1MkZxqm+a80PCJNntOagdnktfw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=q0BInC HRp5e4CdY5Mq2V5V+oTDhPeSE4UmGO4DxfM7I=; b=NeCyHK25ykzOPtl35GhpQH RFq17rk5qyshurZ6yC75MQKHehtVVf8IEgoV/bKovmUTwJcGwZZRX+Cnl1LmlRgc pNivp+wd4jncGMPPbNacNHBU0LvzsCrOOw8aYS+MeuxtSruorsc716Q1+SKwtS/k IM5DCS3qN6f/J0MoxPgrHUwPK8FMgcDIg7v79UamG1gRnjiZyWDAB+C87dioi+3j iwbQGJ+xD88VXURLqGghkcqAhvXI5GUimYIqKzHFc3FLcAZT2RncBd0r4uCcJ9Wc Bx8TQpUVz7H5hDT/s8QIxQ7G1Pke0II24kZka7pouIXOYY9OCPOp+KCB9Rlx3y6w == X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.81]) by mail.messagingengine.com (Postfix) with ESMTPA id DEB54E43E8; Wed, 9 May 2018 21:15:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <152293554290.25904.13212973371332391926@ietfa.amsl.com> Date: Wed, 9 May 2018 21:15:21 -0400 Cc: IETF Gen-ART , draft-ietf-hip-rfc4423-bis.all@ietf.org, hipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6A3F8F42-FCD9-4DFE-B5DD-C80962B69E25@cooperw.in> References: <152293554290.25904.13212973371332391926@ietfa.amsl.com> To: Joel Halpern X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Hipsec] [Gen-art] Genart telechat review of draft-ietf-hip-rfc4423-bis-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 01:15:27 -0000 Joel, thanks for your review. Miika, thanks for your responses. I have = entered a No Objection ballot. Alissa > On Apr 5, 2018, at 9:39 AM, Joel Halpern wrote: >=20 > Reviewer: Joel Halpern > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-hip-rfc4423-bis-19 > Reviewer: Joel Halpern > Review Date: 2018-04-05 > IETF LC End Date: 2018-02-26 > IESG Telechat date: 2018-05-10 >=20 > Summary: This document is ready for publication as an Informational = RFC. > My thanks to the authors for addressing the comments in my previous = review. >=20 > Major issues: N/A >=20 > Minor issues: N/A >=20 > Nits/editorial comments: N/A >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed May 9 18:19:03 2018 Return-Path: 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 E4D4C12E858; Wed, 9 May 2018 18:18:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-hip-native-nat-traversal@ietf.org, Gonzalo Camarillo , 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: <152591513689.10311.5138557900418735242.idtracker@ietfa.amsl.com> Date: Wed, 09 May 2018 18:18:56 -0700 Archived-At: Subject: [Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-native-nat-traversal-28: (with 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 01:18:57 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-hip-native-nat-traversal-28: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm balloting No Objection, but I'm watching the discussion in Eric's ballot thread about reusing pieces of ICE, and I look forward to some discussion about the provisions being made for middleboxes in this draft - I'm not denying that such things exist, only that it would be best if we understood why middleboxes are needed for this usage. From nobody Wed May 9 19:05:20 2018 Return-Path: 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 5E3D2129C70; Wed, 9 May 2018 19:05:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-hip-native-nat-traversal@ietf.org, Gonzalo Camarillo , 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: <152591791834.10400.6957331555512925079.idtracker@ietfa.amsl.com> Date: Wed, 09 May 2018 19:05:18 -0700 Archived-At: Subject: [Hipsec] Ben Campbell's Abstain on draft-ietf-hip-native-nat-traversal-28: (with 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 02:05:18 -0000 Ben Campbell has entered the following ballot position for draft-ietf-hip-native-nat-traversal-28: Abstain 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support all points of Ekr's discuss and comment points. I think this either needs to use ICE mostly as is (maybe with some minor profiling) or it needs to be self-contained here. I understand the material in appendix B, but the current mix seems untenable for implementors. Therefore I am balloting "abstain". I will reconsider that position if there is a substantial reorganization. Substantive Comments: I share Alissa's question about why this is standard track when the previous work has been experimental. §1, second paragraph: The citation for the version of ICE used by "legacy ICE-HIP" should be RFC5245, not the bis version. §2: There are a number of lower-case keywords. Please use the RFC 8174 boilerplate. §4.2: - paragraph 5: Is everything in this paragraph from the ICE specification? I suspect not, but it's hard to tease out what is from ICE and what is new specification. It would be helpful to reference the ICE bits by section number. - paragraph 6: I'm confused in that I thought the previous text said that native ICE-HIP does not use STUN. §6: I am skeptical of the assertion that the security considerations for Native ICE-HIP are no different than those for Legacy ICE-HIP. Editorial Comments: §1, 2nd paragraph: - "responsible of NAT traversal": s/of/to - "responsible of end-host": s/of/to §4.3: "This section describes the usage of a new non-critical parameter type. ": Which is? §4.6, first paragraph: 2nd sentence is hard to parse. From nobody Wed May 9 19:53:52 2018 Return-Path: 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 646AA12D871; Wed, 9 May 2018 19:53:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-hip-rfc4423-bis@ietf.org, Gonzalo Camarillo , 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: <152592082640.10421.10127781203317885108.idtracker@ietfa.amsl.com> Date: Wed, 09 May 2018 19:53:46 -0700 Archived-At: Subject: [Hipsec] Ben Campbell's No Objection on draft-ietf-hip-rfc4423-bis-19: (with 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 02:53:46 -0000 Ben Campbell has entered the following ballot position for draft-ietf-hip-rfc4423-bis-19: No Objection 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-rfc4423-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have mostly just reviewed the diff from RFC4423. My comments are mostly editorial. First, a minor rant that I don't expect to be addressed at this point in the process; I mainly say this to try to discourage it future bis drafts: There are quite a few changes from 4423 that are entirely stylistic, but do not materially change the content or improve readability. I wish people wouldn't do that, because it makes it harder to review material changes with the diff tools. (I will only point out such changes where I think the original was more correct.) -General: There seems to have been a systematic attempt to remove hyphens from compound adjectives. There also seems to be a systematic attempt to change headings from title case to normal sentence case. I suspect the RFC editor will change those all back. Abstract: The abstract manages to completely avoid saying what this namespace is _for_. (Yes, I realize that is old text :-) ) §1, first paragraph: s/ "try and do"/"try to do" §4.2: Please mention the HIT abbreviation in the text, not just the heading. (The text should make sense even without the headings.) §5: - third paragraph: Missing articles before "Left" and "right". - 2nd to last paragraph: Missing article before "HIP layer" (multiple instances). From nobody Wed May 9 22:43:15 2018 Return-Path: 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 B74BB126BFD; Wed, 9 May 2018 22:43:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-hip-native-nat-traversal@ietf.org, Gonzalo Camarillo , 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: <152593099270.10455.6602365389829924376.idtracker@ietfa.amsl.com> Date: Wed, 09 May 2018 22:43:12 -0700 Archived-At: Subject: [Hipsec] Adam Roach's Abstain on draft-ietf-hip-native-nat-traversal-28: (with 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 05:43:13 -0000 Adam Roach has entered the following ballot position for draft-ietf-hip-native-nat-traversal-28: Abstain 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share Ben's concerns about the disjointedness of this document's specification, and am likewise abstaining. My reasons for abstaining are deeper than Ben's, however. I recognize that the effort put into this document is substantial, and that the recommendations I make are unlikely to be taken at this point in time, but I believe that the HIP ecosystem would be far better served by an "RFC 5570 bis" approach rather than a modified form of ICE recast using HIP messages. Among other reasons: several companies already offer geographically-distributed hosted TURN solutions, largely due to the relative popularity of WebRTC. HIP will have to reach a similar level of popularity before HIP-specific relay nodes are similarly commercially available. Using ICE as-is would allow HIP to use those services that are available today. As a further concern, I worry that this pattern may end up replicated in other protocols. For example, although ICE was initially developed with RTP/RTCP in mind, it was not implemented as a series of extensions to RTP or RTCP; instead, it is its own protocol, intended to be re-used in other contexts. I would not like to see, e.g., ICE-like extensions to the QUIC protocol to enable its use in peer-to-peer situations; I would certainly hope that such an effort would use ICE as currently defined. Given that the headline rationale offered in this document is that "Implementing a full ICE/STUN/TURN protocol stack as specified in Legacy ICE-HIP results in a considerable amount of effort and code which could be avoided by re-using and extending HIP messages and state machines for the same purpose," this document puts forth an implication that all protocols could benefit from similar not-quite-ICE-but-almost-ICE extensions. I believe this implication is harmful. I also believe this analysis overlooks the availability of multiple existing, open-source, already-debugged, and "compatible with commercial use" ICE implementations. It is not clear that the four additional reasons offered in Appendix B are sufficient to justify the design. Taken in turn: > For example, ICE is meant for application-layer protocols, whereas HIP > operates at layer 3.5 between transport and network layers. This doesn't have practical effect: ICE is designed to work with generic UDP packet flows, subject only to the ability to demultiplex STUN from such packets. > This is particularly problematic because the implementations employ IPsec > ESP as their data plane: demultiplexing of incoming ESP, HIP and TURN > messages required capturing of all UDP packets destined to port 10500 to > the userspace, thus causing additional software complexity and an > unnecessary latency/throughput bottleneck for the dataplane performance. This doesn't seem like a foregone consequence. If you're using user-space HIP implementations, this user-space diversion is already necessary. If you're using kernel-space HIP implementations, it seems a modest step to add minimal STUN demultiplexing to the kernel implementation that is already performing ESP/HIP demultiplexing. It's possible that I'm misunderstanding some subtle aspect of the way these protocols interact with each other, but isn't this described performance impact simply the result of specific implementation design decisions rather than inherent to the design of RFC 5570's mechanism? > Also, relaying of ESP packets via TURN relays was not > considered that simple because TURN relays require adding and > removing extra TURN framing for the relayed packets. While it's been a while since I've looked at network kernel code, my recollection is that implementation of the POSIX "sendmsg()" system call generally maintains scatter/gather buffers all the way down the stack until such bytes are copied from system memory to the network hardware. Stripping such headers on receipt can be accomplished with simple pointer arithmetic. It's not clear what aspect of the system "simple" is intended to refer to, but both implementation and performance impacts should be immeasurably small when implemented in this way, unless I'm missing something. > Finally, the developers of the two Legacy ICE-HIP implementations concluded > that "effort needed for integrating an ICE library into a HIP > implementation turned out to be quite a bit higher that initially > estimated. Also, the amount of extra code (some 10 kLoC) needed for all > the new parsers, state machines, etc., is quite high and by re-using the > HIP code one should be able to do with much less. This should result in > smaller binary size, less bugs, and easier debugging.". Such size is not inherent in the implementation of ICE: for example, the ICE stack used by Firefox is 2.2 kLoC in size (if you ignore the ~1.2 kLoC of boilerplate copyright notice). Having seen the debugging of an ICE stack up-close-and-personal, I'm pretty comfortable saying that the effort to integrate a working stack has to be orders of magnitude less than implementing even the simplified ICE procedures defined in this document correctly. There are a lot of surprising corner cases that don't really turn up until you get into production. For the foregoing reasons, it is my conclusion that publication of this document is harmful for HIP and is harmful as a precedent that other protocols may mistakenly emulate. I believe that a restructuring of the document to more clearly explain why HIP chose this path while other protocols should not would limit some of these concerns. However, I do not believe that the fundamental flaw -- a partial respecification of ICE for the cited reasons -- can be fixed. I do not support publication of a document describing this mechanism, and encourage the working group to withdraw the document from consideration for publication. To be clear: despite the length and detail of my preceding objections, I recognize that I may be off in the weeds. I am happy to be corrected about any of the assertions I make above, up to and including corrections that make my conclusion incorrect. I will further note that this is not a blocking ballot position, and that, procedurally, the document can be published despite my misgivings. =========================================================================== I have included some additional comments below. --------------------------------------------------------------------------- §1: > As one solution, the HIP experiment report [RFC6538] mentions that > Teredo based NAT traversal for HIP and related ESP traffic (with > double tunneling overhead). This isn't a sentence. Perhaps remove "that"? Also: "Teredo-based" --------------------------------------------------------------------------- §4.6: > The connectivity checks follow the ICE methodology [MMUSIC-ICE], but > UDP encapsulated HIP control messages are used instead of ICE > messages. Only normal nomination MUST be used for the connectivity > checks, i.e., aggressive nomination MUST NOT be employed. The cited document does not describe aggressive nomination, and deprecates its use. Consider removing the mention of aggressive nomination in this document. --------------------------------------------------------------------------- §5.4: > The following NAT traversal mode IDs are defined: > > ID name Value > RESERVED 0 > UDP-ENCAPSULATION 1 > ICE-STUN-UDP 2 > ICE-HIP-UDP 3 This should probably point to the IANA table rather than replicating a snapshot of its contents. --------------------------------------------------------------------------- Appendix B: > o Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP > protocol in order to avoid middlebox tampering. This bullet should explain why such obfuscation is unnecessary. From nobody Thu May 10 02:17:02 2018 Return-Path: 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 B0C9412D947; Thu, 10 May 2018 02:16:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Will LIU To: Cc: draft-ietf-hip-rfc4423-bis.all@ietf.org, hipsec@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152594381959.10451.9615415806066075335@ietfa.amsl.com> Date: Thu, 10 May 2018 02:16:59 -0700 Archived-At: Subject: [Hipsec] Opsdir last call review of draft-ietf-hip-rfc4423-bis-19 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 09:16:59 -0000 Reviewer: Will LIU Review result: Ready Hi all, (Sorry , it seems to me that the notification was blocked by the filter. I guess it's a little bit late.) I have reviewed draft-ietf-hip-rfc4423-bis-19 as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. “This memo describes a new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. It incorporates lessons learned from the implementations of RFC 5201 and goes further to explain how HIP works as a secure signaling channel.” My overall view of the document is 'Ready' for publication. Some small ones: 1. Especially, I am glad to see the security consideration part well explained. I guess it's still worth writing something about the security tradeoff influence for the different modes mentioned in previous sections. In fact, there are some words in previous sections, maybe a summary can be put here. 2. It's good to have a single subsection about " Answers to NSRG questions". However, maybe it's better to put it in appendix? Regards, Will (Shucheng LIU) From nobody Thu May 10 03:00:52 2018 Return-Path: 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: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-hip-native-nat-traversal@ietf.org, Gonzalo Camarillo , 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: Subject: [Hipsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-hip-native-nat-traversal-28=3A_=28with_DISCUSS_and_COMMENT=29?= 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. From nobody Mon May 21 17:52:49 2018 Return-Path: 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 29C7812D86F; Mon, 21 May 2018 17:52:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-hip-dex@ietf.org, Gonzalo Camarillo , 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: <152695036709.7650.1412062169882723188.idtracker@ietfa.amsl.com> Date: Mon, 21 May 2018 17:52:47 -0700 Archived-At: Subject: [Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-dex-06: (with 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 00:52:47 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-hip-dex-06: No Objection 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-dex/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm not an expert on what people expect about security, but I'm wondering if there's a little too much distance between this text in the Abstract, This document specifies the Host Identity Protocol Diet EXchange (HIP DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The HIP DEX protocol design aims at reducing the overhead of the employed cryptographic primitives by omitting public-key signatures and hash functions. In doing so, the main goal is to still deliver similar security properties to HIPv2. and this text in the Introduction, The main differences between HIP BEX and HIP DEX are: (snip) 2. HIP DEX forfeits the HIPv2 Perfect Forward Secrecy property of HIPv2 due to the removal of the ephemeral Diffie-Hellman key agreement. Would the average reader consider "no PFS" to be similar to PFS? (Please note that I'm not questioning the choice made in DIX, only the way that choice is described in the Abstract) I'm curious about whether a couple of other differences named in the Introduction would also qualify as similar, but let's start with PFS. I'm also curious about whether 1.1. The HIP Diet EXchange (DEX) (snip) HIP DEX does not have the option to encrypt the Host Identity of the Initiator in the 3rd packet. The Responder's Host Identity also is not protected. Thus, contrary to HIPv2, HIP DEX does not provide for end-point anonymity and any signaling that indicates such anonymity should be ignored. qualifies as "similar", but I don't have a good sense of how much this matters in current and expected HIP deployments. I'm hardly the smart one about this, but is o HIP DEX lacks the Perfect Forward Secrecy (PFS) property of HIPv2. Consequently, if an HI is compromised, all HIP connections protected with that HI are compromised. correct? I was expecting to see something like "if an HI is compromised, all previous HIP connections protected with that HI are compromised". The version of this draft I'm reviewing has 57 occurrences of the word "should". I'm not seeing very many cases where the surrounding text explains why an implementation would not do what it SHOULD do, and I'm not seeing many cases where the surrounding text explains what the peer implementation should do, if the other endpoint doesn't do what it SHOULD do, although many of those cases might be captured in the state diagrams in the document. In this text, By eliminating the need for public-key signatures and the ephemeral DH key agreement, HIP DEX reduces the computation, energy, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ transmission, and memory requirements for public-key cryptography ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (see [LN08]) in the HIPv2 protocol design. Moreover, by dropping the cryptographic hash function, HIP DEX affords a more efficient ^^^^^^^^^^^^^^^^^^^^^^^^ protocol implementation than HIP BEX with respect to the ^^^^^^^^^^^^^^^^^^^^^^^ corresponding computation and memory requirements. is "efficient" the right word, in the second sentence? This seems to mirror that "reducing requirements" effect from the first sentence - I'd assume that if you were comparing efficiencies, you'd be comparing two things with equivalent functionality. I'm sure I'm not reading this correctly, but in this text In the second case, the HIP DEX implementation (Responder) inspects the Initiator's HIT on reception of an I1 packet. If the OGA ID field of this HIT does not indicate the HIP DEX HIT Suite ID, the HIP DEX implementation cancels the handshake and sends an ICMP packet with type Parameter Problem, with the Pointer pointing to the source HIT, to the Initiator. As an adversary could also send such an ICMP packet in a man-in-the-middle attack with the aim to prevent the HIP ^^^^^^^^^^^^^^^^^ DEX handshake from completing, the Initiator SHOULD NOT react to an ICMP message after sending the I1 until a reasonable delta time to get the real Responder's R1 HIP packet. I would have thought that this was a good plan to defend against an off-path attacker, because ICMP is helpfully unauthenticated, and if you were on-path (so, man-in-the-middle), you'd probably be doing things that were much more aggressive (like trying to impersonate the other end). Am I getting this wrong?