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

Miika Komu <> Thu, 30 June 2016 08:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 671B912D8F0 for <>; Thu, 30 Jun 2016 01:13:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cwRSMW5VRCis for <>; Thu, 30 Jun 2016 01:13:12 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E6A0112D759 for <>; Thu, 30 Jun 2016 01:13:11 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-8f-5774d4951930
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id B9.CB.12926.594D4775; Thu, 30 Jun 2016 10:13:09 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 30 Jun 2016 10:12:50 +0200
To: Jeff Ahrenholz <>, "" <>
References: <> <> <>
From: Miika Komu <>
Organization: Ericsson AB
Message-ID: <>
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: <>
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: <>
Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 

"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