Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt

Jeff Ahrenholz <j.ahrenholz@temperednetworks.com> Thu, 30 June 2016 16:33 UTC

Return-Path: <j.ahrenholz@temperednetworks.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDFB12D1B8 for <hipsec@ietfa.amsl.com>; Thu, 30 Jun 2016 09:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hfc_Bkde12sC for <hipsec@ietfa.amsl.com>; Thu, 30 Jun 2016 09:33:45 -0700 (PDT)
Received: from out.west.exch081.serverdata.net (cas081-co-6.exch081.serverdata.net [199.193.204.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CAB12D149 for <hipsec@ietf.org>; Thu, 30 Jun 2016 09:33:23 -0700 (PDT)
Received: from MBX081-W5-CO-2.exch081.serverpod.net (10.224.129.85) by MBX081-W5-CO-1 (10.224.129.84) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 30 Jun 2016 09:33:22 -0700
Received: from MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) by MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) with mapi id 15.00.1178.000; Thu, 30 Jun 2016 09:33:22 -0700
From: Jeff Ahrenholz <j.ahrenholz@temperednetworks.com>
To: Miika Komu <miika.komu@ericsson.com>, "hipsec@ietf.org" <hipsec@ietf.org>
Thread-Topic: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt
Thread-Index: AQHRzVleTAP7xruKpU6gf7y7RtV0i5/3khUAgAEr1QCACe+WgP//kggA
Date: Thu, 30 Jun 2016 16:33:22 +0000
Message-ID: <F288D398-C77B-404B-81F9-74028D38FDFC@temperednetworks.com>
References: <20160623141232.31224.21763.idtracker@ietfa.amsl.com> <576BF266.4040703@ericsson.com> <5C1F7EB9-3B99-47E1-A929-B79E97F56F57@temperednetworks.com> <577543A1.9060507@ericsson.com>
In-Reply-To: <577543A1.9060507@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [216.168.34.194]
Content-Type: text/plain; charset="utf-8"
Content-ID: <0E666D5D0C15A74CAB09D971CF1B54FB@exch081.serverpod.net>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/y0XjWPdKEKJR2AKjIKAwzpNwX2U>
Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2016 16:33:48 -0000

On 6/30/16, 9:06 AM, "Miika Komu" <miika.komu@ericsson.com> wrote:
>> Seems like a good idea. No ESP_TRANSFORM -> no need to establish two-way comms between peers.
>> For example, when performing a registration procedure with a relay server.
>
> The direct path could be, of course, used for exchange HIP messages 
> directly (including hiccups v2). Does this make sense?

yes, makes sense

> If not, what should happen when both ESP_TRANSFORM and ICE-HIP-UDP are 
> both negotiated? Or should we just be proactive and state that upon 
> receiving R1, the Initiator MUST NOT include ICE-HIP-UDP if it is not 
> going to employ any ESP_TRANSFORM.

This proposed sentence seems like a good revision.

> Connectivity tests implement the return routability checks. Currently, 
> the NAT mobility triggering mechanism mimics the tree-way procedure in here:
>
> https://tools.ietf.org/html/draft-ietf-hip-rfc5206-bis-12#section-3.2.1
>
> I thought that would nice for implementers but strictly speaking steps 
> 5-6 could skipped since the connectivity checks actually implement the 
> return routability checks.
>
> I can change this if you agree?

Yes, I agree they can be skipped. 
The connectivity checks are more UPDATE packets, and fewer update round-trips seems like faster mobility handover.

-Jeff