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."
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
