I read ipsec-ike-tcp-00. I found it very clear. section 3 says: > An initiator using this policy MUST NOT go to TCP if the responder > has not indicated support by sending the IKE_TCP_SUPPORTED > notification (Section 2.5) in the Initial response.
...
> Yet another policy would be to begin by using UDP, and at the same
> time set up the TCP connection. If at any point the TCP handshake
> completes, the next requests go over that connection. This method
These two parts seem to be in contradiction unless this isn't the first
time the initator has talked to this responder, and cached this state.
Even so, a responder that is under attack may want to limit who it talks
TCP to, but the kernel usually does the three-way handshake itself.
The responder might want
1) to prioritize which initiators are allowed to use TCP by omitting
the IKE_TCP_SUPPORTED payload.
2) to never have initiators use TCP for the initial exchange so that
it can use COOKIE payloads.
> the three-way handshake just when IKE over UDP has finished. The
> requirements from the responder ensure that all these policies will
> work.
An initiator that did this would seem to be effectively taking twice the
resources on the responder.
I think that it's important to note really loundly, and maybe
repeatedly, that the duration of the TCP connection is not related to
the duration of the IKE SA.
--
Michael Richardson
-on the road-
pgp5oV64askdr.pgp
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
