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

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

_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec