Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

Miika Komu <> Wed, 09 May 2018 21:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEB80129C56 for <>; Wed, 9 May 2018 14:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.311
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x6IHlgxJ4lSy for <>; Wed, 9 May 2018 14:21:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A32C612DA6C for <>; Wed, 9 May 2018 14:21:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailgw201801; c=relaxed/simple; q=dns/txt;; 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 (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 19.A4.28172.D6663FA5; Wed, 9 May 2018 23:21:49 +0200 (CEST)
Received: from [] ( by ( 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 <>, "" <>, "" <>, "" <>
References: <> <> <> <> <> <>
From: Miika Komu <>
Organization: Ericsson AB
Message-ID: <>
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: <>
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-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


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