Andrew Cagney <[email protected]> wrote: > Trust hasn't yet been established; and when it has it's too late. For instance:
> initial initial exchanges happen
> A still has no IKE SA it fully trusts and a Child SA that isn't
established
> A initiates IKE_AUTH w/ Child SA to B
> A responds to IKE_AUTH w/ seemingly same Child SA from B
The worst pathology, particularly given big-expensive multi-packet
quantum-safe authentications, is that both ends start IKE_INIT,
and then go into IKE_INTERMEDIATE.
A is responding to B's init, but hasn't finished (might not even know it's
B), and then A sees that it needs to talk to B, and *it* starts.
I think that this is what you are talking about, and I think a lot of detail
is buried in the "initial initial exchanges happen" point above.
The resulting traffic could then start to cause both attempts to go into
retransmission. (Or stupid IKE helpers in NAPT devices think they know better)
> At this point A has an IKE SA it trusts (initiated by the peer). Does
> it go with that or hold its breath and hope its own request comes
> back.
> Symmetry means the peer is going to do the same thing, hence a cross.
> One of the original recommendations for handling this was to just
> leave the two SAs. Not sure that's the best when they're fighting
> over dedicated h/w.
I am not certain what hardware would be dedicated :-)
Like an HSM/TEE/TPM that is going to do some quantum-safe work, but is
intentionally slow/single-threaded? (as TPMs often are)
I think that a good *heuristic* would be for an end-point to note that it has
multiple exchanges underway with the same IP address, and if it is the
initiator of any of them, then it should consider if, given the
RFC7296 section 2.8.2. says to pick the one with the lowest nonce,
if the SA that it is initiating would be the winning SA.
If the SA that it is initiating would lose, then it could just delay
it's next state change. That is, even though it got some responder
message, it would not proceed to the next message in the state machine for an
extra few s.
If it turns out that the other SA does not succeed, then there is just a
short delay.
Perhaps obvious, if responding to multiple SA requests from the same IPv4,
then NAT44 might just mean it's multiple clients reconnecting, and the
resulting SAs would not overlap.
That TEMPORARY_FAILURE is called out in 2.8.2, and I suspect that there is a
higher probability of this happening when the exchange is longer.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
** My working hours and your working hours may be different. **
** Please do not feel obligated to reply outside your normal working hours **
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
