Re: [Hipsec] IESG review of NAT traversal draft and encrypted parameters

Jeff Ahrenholz <> Thu, 08 November 2018 16:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D69BB12D4E6 for <>; Thu, 8 Nov 2018 08:22:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wf6jHYlWGe19 for <>; Thu, 8 Nov 2018 08:22:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1899412D4EE for <>; Thu, 8 Nov 2018 08:22:17 -0800 (PST)
Received: from ( by MBX081-W5-CO-1 ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 8 Nov 2018 08:22:16 -0800
Received: from ([]) by ([]) with mapi id 15.00.1367.000; Thu, 8 Nov 2018 08:22:16 -0800
From: Jeff Ahrenholz <>
To: Miika Komu <>, hip WG <>
Thread-Topic: [Hipsec] IESG review of NAT traversal draft and encrypted parameters
Thread-Index: AQHUd383rljQQyA9SU6NRqaWcQec9Q==
Date: Thu, 08 Nov 2018 16:22:16 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Hipsec] IESG review of NAT traversal draft and encrypted parameters
X-Mailman-Version: 2.1.29
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, 08 Nov 2018 16:22:20 -0000


>    I don't think we need XORring with HIP because we have more powerful 
>    mechanisms in HIP. So, I am going to add some text that mandates that 
>    the LOCATOR parameter must be encapsulated inside ENCRYPTED parameter 
>    when ICE-HIP-UDP will be used. The tradeoff here is that we favor 
>    end-host privacy at the cost middlebox transparency.

Seems like a good use of ENCRYPTED to me.

I'm not sure what kind of middlebox would need to know all of the address candidates. Maybe some extra signaling could be devised when that needs to happen (like a HIP-aware middlebox where addresses can be communicated via HIP.)

Thanks for continuing the work on this!