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

Miika Komu <miika.komu@ericsson.com> Thu, 30 June 2016 08:13 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 671B912D8F0 for <hipsec@ietfa.amsl.com>; Thu, 30 Jun 2016 01:13:14 -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 cwRSMW5VRCis for <hipsec@ietfa.amsl.com>; Thu, 30 Jun 2016 01:13:12 -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 E6A0112D759 for <hipsec@ietf.org>; Thu, 30 Jun 2016 01:13:11 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-8f-5774d4951930
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B9.CB.12926.594D4775; Thu, 30 Jun 2016 10:13:09 +0200 (CEST)
Received: from [100.94.2.57] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.294.0; Thu, 30 Jun 2016 10:12:50 +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>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <5774D482.6010509@ericsson.com>
Date: Thu, 30 Jun 2016 11:12:50 +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: <01A2E941-8F85-4964-8B2A-347CF48B21A0@temperednetworks.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000608040209030603050506"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2K7n+7UKyXhBv03zCymLprMbNE65Saz A5PHkiU/mTy27ulkCWCK4rJJSc3JLEst0rdL4MpYPn8Rc8EDm4qllxewNTButehi5OSQEDCR mH9mCRuELSZx4d56IJuLQ0jgCKPEp69roZyVjBIvup4yglQJC/hI3Pz9CMwWEYiRuDhvDQtE 0UJGiTk3JrGDJNgEtCRW3bnODGLzC0hKbGjYDWbzCmhLrLp+jQnEZhFQlTjYcQBstahAhMSs 7T+YIGoEJU7OfMICYnMKeEhMfHKWFWQBs0A3o8TWT0uBBnEAbVORuHgseAKjwCwkLbOQlYEk mAXMJOZtfghla0ssW/gayraWmPHrIBuErSgxpfshO4RtKvH66EdGCNtYYtm6v2wLGDlWMYoW pxYn5aYbGeulFmUmFxfn5+nlpZZsYgRGxcEtv1V3MF5+43iIUYCDUYmHdwFPSbgQa2JZcWXu IUYVoDmPNqy+wCjFkpefl6okwit6GSjNm5JYWZValB9fVJqTWnyIUZqDRUmc1/+lYriQQHpi SWp2ampBahFMlomDU6qBkaNbTN7TzqNUR4Eno3Kl/y+5W6Lbtm/d87bsSoB0O9+rex+LPB1X riyclNkudq1wttvHQ1tdygu+CE44pBR+ZH/aK+PCzFlN6XKr9lYre15Tetqz6tmdnJY9HMZ3 +ViVuSYLvqxLSFgZ5Nj0fJ7e0g0OFimTDUrFb08ts/B8X3smu/dSudNDJZbijERDLeai4kQA TkSq4pICAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/MCpUb5ecpufK3_tsl44vQ05XOcY>
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 08:13:14 -0000

Hi Jeff,

On 06/24/2016 12:49 AM, Jeff Ahrenholz wrote:
> Hi Miika,
> I was reviewing this section...
>
>> * 4.12.3.  Handling Conflicting SPI Values
>>      * Should the Responder send a notify on SPI collision?
>>      * Removed text about registering with multiple addresses because I
>> think this does not work with HIP (or at least, requires multihoming)
>
> When there is a SPI collision, it does seem that we would want a new type of NOTIFY to be sent.
>
> Otherwise it seems the Initiator will be stuck in the state I2-SENT, retransmitting the I2 until going back to the failure state, when it can retry the BEX from the beginning again.
>
> Maybe it needs to be an ICMP message (and not NOTIFY) since there is not yet an association between the two peers (RFC 7401 section 4.3).

good catch, no host association -> ICMP should be used.

The SPI collision issue seems to be a bit more generic, possibly 
influencing also RFC7402. Or is it actually a real issue? From the nat 
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."

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).

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."