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

Miika Komu <miika.komu@ericsson.com> Fri, 01 July 2016 10:40 UTC

Return-Path: <miika.komu@ericsson.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 4AF6412D550 for <hipsec@ietfa.amsl.com>; Fri, 1 Jul 2016 03:40:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 PwK5FZGZ0mM7 for <hipsec@ietfa.amsl.com>; Fri, 1 Jul 2016 03:40:48 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDB812D548 for <hipsec@ietf.org>; Fri, 1 Jul 2016 03:40:47 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-ee-577648ad1cbd
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F5.EC.12926.DA846775; Fri, 1 Jul 2016 12:40:45 +0200 (CEST)
Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.294.0; Fri, 1 Jul 2016 12:40:45 +0200
To: Jeff Ahrenholz <j.ahrenholz@temperednetworks.com>, "hipsec@ietf.org" <hipsec@ietf.org>
References: <20160623141232.31224.21763.idtracker@ietfa.amsl.com> <576BF266.4040703@ericsson.com> <01A2E941-8F85-4964-8B2A-347CF48B21A0@temperednetworks.com> <5774D482.6010509@ericsson.com> <350A26F6-5DE6-4B00-A354-1186D37B6883@temperednetworks.com>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <577648AD.3000907@ericsson.com>
Date: Fri, 1 Jul 2016 13:40:45 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <350A26F6-5DE6-4B00-A354-1186D37B6883@temperednetworks.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080704040507050503000406"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7q+5aj7JwgxNP9C2mLprMbNE65Saz A5PHkiU/mTy27ulkCWCK4rJJSc3JLEst0rdL4Mp4tfcha8Ea14rVe5MbGOfbdzFyckgImEh8 P/+CGcIWk7hwbz1bFyMXh5DAEUaJf+sfMUE4qxglug6eYASpEhbwkbj5+xGYLSIQI3Fx3hoW iKJGJolJ/TvYQBJsAloSq+5cBxvLLyApsaFhN5DNwcEroC1xYLYfSJhFQEXi8ZoPYOWiAhES s7b/YAKxeQUEJU7OfMICYnMKeEg09SxnB5nPLNDNKPH2+n8mkDlCQM0XjwVPYBSYhaRlFrIy kASzgJnEvM0PmSFsbYllC19D2dYSM34dZIOwFSWmdD9kh7BNJV4f/cgIYRtLLFv3l20BI8cq RtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMCIOLjlt+oOxstvHA8xCnAwKvHwLjhXGi7EmlhW XJl7iFEFaM6jDasvMEqx5OXnpSqJ8L51LgsX4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuv/UjFc SCA9sSQ1OzW1ILUIJsvEwSnVwNidpf9k3w37U++tkrcoLWlYcGUi+07ua3tSd6yo1JFUN+Dg zHlvxjmp/+r5iLtyDdmP6noCG14vCbjS3ux35f51//9Xw0oFsr9uDM58pGNwgHtq/IpbZ+Zq vLrqdHeCwgzRKU1bGKXvr7h/blbTOv2zjbcu6r5WrCo/WSIRVbxX2UGp2CLyurESS3FGoqEW c1FxIgDOaHL+kAIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/corseYZAfZdypkkB8VEhmXW2x34>
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: Fri, 01 Jul 2016 10:40:50 -0000

Hi Jeff,

On 06/30/2016 07:08 PM, Jeff Ahrenholz wrote:
> Miika,
>
>> On 6/30/16, 1:12 AM, "Miika Komu" <miika.komu@ericsson.com> wrote:
>>
>> Is it actually a problem for the Responder that two different Initiators
>> happen to claim different SPIs? The Initiators have different IP
>> addresses (or at least UDP ports if they are behind the same NAT).
>
> You’re right, it seems like it is not a problem for the Responder since there are different IP/ports.

Ok. I added the following sentence (separated with starts) to the draft:

"In first case, the SPI collision problem occurs when two
Initiators run a base exchange to the same Responder (i.e. registered 
host), and both the Initiators claim the
same inbound SPI. ***This is not a problem for Responder
since the two Initiators can be distinguished by their transport
addresses. *** However, it is an issue for the data relay
because the it cannot demultiplex packets from the Initiator
to the correct Responder."

>> It is a problem for the data relay, so the text says:
>>
>> "Upon receiving an I2 with a colliding SPI, the Responder MUST not
>> include the relayed address in the R2 message because the data relay
>> would not be able demultiplex the related ESP packet to the correct
>> Initiator."
>
> Does this mean the Responder should not even send the R2 message upon collision?

Since we agreed that it is not an (IPsec) problem for the Responder, the 
answer is "no". The text says that the Responder can send R2 but without 
the locator of the data relay because the data relay would be confused 
about the conflicting SPIs.

> The draft also says this:
>
>   “The described
>     collision scenario can be avoided if the Responder delivers a new
>     relayed address candidate upon SPI collisions.  Each relayed address
>     has a separate UDP port reserved to it, so the relay can demultiplex
>     properly conflicting SPIs of the Initiators based on the SPI and port
>     number towards the correct Responder.”
>
> What if the Responder sends the R2 message (established state)  and then immediately follows with an UPDATE packet to initiate a rekey?
> The rekey would cause both sides to select new SPI values.

Good catch, added:

"The same applies also the handover procedure; the
registered host MUST NOT include the relayed address candidate
when sending its new locator set in an UPDATE to its peer if it would 
cause a SPI conflict with another peer."

> Not sure what happens if you send the R2 without the relayed address -- proper state not created on the Initiator?

If NAT connectivity tests fail to set up a direct path, the indirect 
path through the data relay will be unavailable => no path for data traffic.