[email protected] writes: > Yaron and Tero, > > Hmm... it seems changing your own IKE SPI during an IKE_SA does not > work anyway, so if you get a packet where the peer's SPI is different > (than what it used for this IKE_SA earlier), it did not come from > a spec-compliant peer. > > The question is whether we should require the recipient to check > that the peer's SPI has not changed. To me, it looks like this would > not be an interoperability issue (the peer is doing something outside > the spec, so it can't expect any particular behavior from us)... > > Tero, how did you encounter this in the interops? (And was the node > sending this buggy, or did it consider itself to be behaving according > to the spec?)
The sender was TAHI project IKEv2 tester, and if I remember correctly they sent that on purpose and they expected the other end to detect that SPI changed, and not to continue because of that. Our code simply used our own SPI as that is sufficient to find the IKE SA and we didn't really care what was in the other ends SPI. I did add additional check to our code to check the other ends SPI and drop the packet if it is changed. > If it's not an interop issue, and not a security issue, then I'm > not sure if mandating such check is needed. But are there some > security implications? I agree that there is no real need to mandate such check, but if IKEv2 tester implementations are requiring such check that will be de-facto requirement to add such check, as otherwise you will not pass their tests. So for that it is interoperability issue, as you cannot pass their interoperability tests if you do not check it. So thats why I think it would be good to say that either it is valid to check only your own SPI or that you MUST check both spis. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
