Andrew Cagney <[email protected]> wrote: >> 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.
> I'm trying to keep things focused on an IKE_AUTH exchange, where trust
> and the Child SA cross. A variant would be childless IKE SAs where
> both ends immediately initiate a CREATE_CHILD_SA (I've seen this in
> the field with a second SA).
Yes, but we can do better!
> With an overlap such as:
> A initiates IKE_SA_INIT to B
> A responds to IKE_SA_INIT from B
> A responds to IKE_AUTH from B
(1) A->B IKE_SA_INIT
(1) B->A respond to SA_INIT
(2) B->A IKE_SA_INIT
(2) A->B respond (**)
[##]
(1) A->B IKE_INTERMEDIATE
2..3..4..
(2) B->A IKE_INTERMEDIATE
2..3..
(1) A->B IKE_AUTH
(1) B->A responds
could be many packets to get quantum-safe signature!
(2) B->A IKE_AUTH
(2) A->B responds
could be many packets to get quantum-safe signature!
[!!]
>> 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.
> Yea, that's why I'm putting it out there.
> Unfortunately, it's surrounded by words making it clear it is only for
> use when a rekey crosses. And the value used to break the tie is
> comming from a not-yet-trusted IKE_SA_INIT exchange.
Exactly, in order to pick a clear winner, we need to know who we are talking
to, which means finishing the IKE_AUTH. Then we consistently pick the
winner, and the initiator of the loser kills it.
So I'm suggesting that at the (**) the nonces from both (1) and (2) are
visible, and one can know which will be the winner.
I'm suggesting that *A*, if it sees that it's SA would be the loser,
would then, rather than immediately doing [##], would instead insert a
backoff delay of a few seconds. Since A is initiator, it can go as slow as
it likes, and at [!!], A can see that it has a valid SA (2), and just stop.
I don't *think* A has to do any cleanup here.
I can't recall if A would be allowed to send a delete for (1), using SA (2).
> Hmm, perhaps the way out is to let both ends establish, but then the
> end with the lowest trusted nonce, initiate a delete. Probably going
> hand-in-hand with kernel policy updates to move, instead of remove,
> rules.
That's what RFC7296 already says, it just takes a lot of work to establish
both IKE SAs, and if the child SA is created, then it sucks up hardware (as
you point), and can also wind up having two unidirectional IPsec SAs, if the
delete process is not speedy. (I think that might be a hard-to-replicate bug)
--
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]
