IETF Logo Mail Archive

Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-23

Jeff Ahrenholz <j.ahrenholz@temperednetworks.com> Wed, 29 November 2017 18: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 71520127B73 for <hipsec@ietfa.amsl.com>; Wed, 29 Nov 2017 10:33:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXDavPYtmmfS for <hipsec@ietfa.amsl.com>; Wed, 29 Nov 2017 10:33:38 -0800 (PST)
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 55B98127444 for <hipsec@ietf.org>; Wed, 29 Nov 2017 10:33:38 -0800 (PST)
Received: from MBX081-W5-CO-2.exch081.serverpod.net (10.224.129.85) by MBX081-W5-CO-2 (10.224.129.85) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 29 Nov 2017 10:33:36 -0800
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; Wed, 29 Nov 2017 10:33:35 -0800
From: Jeff Ahrenholz <j.ahrenholz@temperednetworks.com>
To: Miika Komu <miika.komu@ericsson.com>, hip WG <hipsec@ietf.org>
Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-23
Thread-Index: AQHTY4Qbc9UVvM0MgUGgSqgkrV6YN6MqEKMAgAIa7QD//46JgA==
Date: Wed, 29 Nov 2017 18:33:35 +0000
Message-ID: <C85AFA4F-88E9-469C-8422-B07E96EDFC30@temperednetworks.com>
References: <7d84466e-4532-a06a-9c21-772040ffaf29@ericsson.com> <BFFD9C72-E5AB-4284-BC8F-45605D0D2608@temperednetworks.com> <516c85e1-468b-6779-51e4-44f26180719e@ericsson.com>
In-Reply-To: <516c85e1-468b-6779-51e4-44f26180719e@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: <FDA82BFDFE9ACC4CB75E9AC9B7EF0FF1@exch081.serverpod.net>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/CoHKPNWcc6N56oI4ufMle5L2y5o>
Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-23
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Nov 2017 18:33:39 -0000

Miika,

>    now it says:
>    
>    It SHOULD wait for all of them to respond for a configurable time, by 
>    default two minutes, and then continue with the handover procedure...

OK, various changes look good.

>> Is it possible then to have no valid locators here, due to the SPI collision? What will happen then?
>    The hosts will anyway send their local locators and server reflexive 
>    ones, and only the relayed one must be omitted. So, this means that no 
>    connectivity if NAT traversal fails. Remember that this is just a back 
>    up plan which the data relay client executes only when it fails to 
>    register for a new relayed candidate *and* the SPI would conflict. In 
>    other words, a data relay client MAY reuse server relayed candidates 
>    only if SPI does not conflict.
>    
>    (I did not correct anything related to this, let me know explicitly if 
>    you would like to see some changes)

OK, thanks for the explanation. I don’t think any further changes are needed here.

-Jeff

v2.23.0 | Report a Bug | By Email