Wang Xi <[email protected]> wrote: > Instead of silently delaying/ignoring packets (which, as Andrew > correctly pointed out, triggers exponential retransmissions and > timeouts on the peer) or forcing the kernel to intervene, why don't we > introduce an Explicit Fast Refusal mechanism at the application layer?
It doesn't work like that. IKEv2 isn't TCP.
In IKEv2 only the initiator retransmits, and according to its schedule/whim.
Even if the window is larger than one, it's still up to the initiator to
decide how many flights of packets to emit. Clearly IKE_INTERMEDIATE
benefits from pushing more packets into the network at the same time.
> The proposal: Once the IKE_SA_INIT exchange completes, both ends
> immediately compute the Nonce tie-breaker. The party that determines
> its SA will be the "loser" doesn't need to silently endure the heavy
> PQC IKE_AUTH exchange just to delete it later.
I believe that is already the case in RFC7296.
Since it depends upon nonces, it can be determined before authentication even
completes. Of course, you can't be sure what is going until auth is done,
so you can not STOP/cancel the losing SA.
My proposal is simple: if one is the initiator of an SA with an IP address
that one is also a responder for (or that situation begins), then just slow
down.
1) If it's really the same peer, then after AUTH, one sees that, and the
initiator just deletes its state. Since it hasn't completed AUTH, the
responder should garbage collect it's half-open state.
INITIAL_CONTACT helps here, I think.
2) If it's not the same peer (many peers behind NAT44), then as each of those
initiators reach their AUTH state, it will be clear to our end that
it's not the same.
Each time a peer at that same IP reaches their AUTH state, then this end
should
remove the "slow-down".
3) this end does not *stop*, just puts more gaps between initiator messages.
Outright stopping opens one up to a denial of service, I think.
Could there be two groups of peers behind two NAT44 each trying to reach each
other? Maybe... but there is only one port-500/4500 at each end, so
the rest of the entities must be initiators, with only one responder at each
end.
Now, if the calculation of the nonce tie-breaker indicates that our end would
win, then really, it does nothing different. If the other end does not
slow down, then tough, we wind up with two IKE SAs. Perhaps if there is
acceleration hardware, then delaying the CHILD SA creation makes sense.
That is, don't do the CHILD SA create in the same message as the AUTH.
--
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]
