IETF Logo Mail Archive

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

Jeff Ahrenholz <j.ahrenholz@temperednetworks.com> Thu, 30 June 2016 16:08 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 173FD12D1BE for <hipsec@ietfa.amsl.com>; Thu, 30 Jun 2016 09:08:14 -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 v3lhBNeBWO5p for <hipsec@ietfa.amsl.com>; Thu, 30 Jun 2016 09:08:12 -0700 (PDT)
Received: from out.west.exch081.serverdata.net (cas081-co-8.exch081.serverdata.net [199.193.204.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11F712D1B9 for <hipsec@ietf.org>; Thu, 30 Jun 2016 09:08:12 -0700 (PDT)
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; Thu, 30 Jun 2016 09:08:11 -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:08:11 -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/3khUAgAAFU4CACpGgAIAAD3eA
Date: Thu, 30 Jun 2016 16:08:11 +0000
Message-ID: <350A26F6-5DE6-4B00-A354-1186D37B6883@temperednetworks.com>
References: <20160623141232.31224.21763.idtracker@ietfa.amsl.com> <576BF266.4040703@ericsson.com> <01A2E941-8F85-4964-8B2A-347CF48B21A0@temperednetworks.com> <5774D482.6010509@ericsson.com>
In-Reply-To: <5774D482.6010509@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: <A9F5CE11CEF6E4489BCD332B8C4CD298@exch081.serverpod.net>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/MhXUyBF24LdKAZVeVg6Vv2o_Xag>
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:08:14 -0000

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.

> 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?

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.

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

-Jeff

v2.14.0 | Report a Bug | By Email