On Thu, 28 May 2015, Yoav Nir wrote:
Yoav Nir writes:
When the tunnel is first set up, it is negotiated in the IKE_AUTH
exchange. Diffie-Hellman is not performed, so the mismatched
configuration is not detected - traffic flows through the tunnel.
If your setup is set to that you configure only one Diffie-Hellman for
the IKEv2, which is then used for both IKE SA and Child SAs, then you
would notice this misconfiguration immediately.
My product has a separate configuration for phase 1 Diffie-Hellman group and
phase 2 Diffie-Hellman group. Thinking it over, I cannot explain why this is
needed, but at least StrongSwan also specifies ESP groups separately from IKE
groups.
I had a long talk with Tero a few IETF's ago, and he was pretty
convincing that it makes no sense whatsoever to have different
phase 1/2 diffie hellman groups.
It does lead to a more complicated exchange. With strongswan, we need to
set the modp group on the esp line to avoid failing if the phase1
negotiates a different modp group depending on the peer, because we will
pick the same modp group in phase2 that we negotiated for phase1.
As far as I can tell, this behavior is consistent with the RFC, but
the user experience is very strange. Traffic should either flow or
not flow - it should not stop at rekeying.
Yes. We ran into that with pfs= as well. We never reject pfs since it is
always better, but then at rekey time, depending on which endpoint
started the rekey, the proposal would be rejected on pfs. So we changed
it to not allow pfs when pfs=no.
Am I missing something?
Do not misconfigure your systems…
I’ll tell the users…
Try to tell your webgui developers instead? :)
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
