Hi Jeff, On 06/30/2016 07:08 PM, Jeff Ahrenholz wrote:
Miika,On 6/30/16, 1:12 AM, "Miika Komu" <miika.k...@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.
Ok. I added the following sentence (separated with starts) to the draft: "In first case, the SPI collision problem occurs when twoInitiators run a base exchange to the same Responder (i.e. registered host), and both the Initiators claim the
same inbound SPI. ***This is not a problem for Responder since the two Initiators can be distinguished by their transport addresses. *** However, it is an issue for the data relay because the it cannot demultiplex packets from the Initiator to the correct Responder."
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?
Since we agreed that it is not an (IPsec) problem for the Responder, the answer is "no". The text says that the Responder can send R2 but without the locator of the data relay because the data relay would be confused about the conflicting SPIs.
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.
Good catch, added: "The same applies also the handover procedure; the registered host MUST NOT include the relayed address candidatewhen sending its new locator set in an UPDATE to its peer if it would cause a SPI conflict with another peer."
Not sure what happens if you send the R2 without the relayed address -- proper state not created on the Initiator?
If NAT connectivity tests fail to set up a direct path, the indirect path through the data relay will be unavailable => no path for data traffic.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
