|Main Archive Page > Month Archives > ipsec archives|
Yoav Nir wrote:
> I agree that this is a real problem not just because a peer may
> be configured to do group #5 for IKE and group #2 for IPsec, but
> because some IKE peers may prohibit D-H for IPsec (for example RA
> concentrators) while others may require it. This is clearly a
> mismatched configuration, yet it will only be discovered when the
> IPsec SA needs to be rekeyed.
> So I think your idea is a good one, but it is in conflict
> with RFC 4306.
> I can think of two ways to fix this:
> 1. Add a notification to IKEv2 with a name like
> WILL_DO_PFS_ON_REKEY that can be added to the AUTH exchange. It
> will specify the groups supported (maybe only zero for no PFS). A
> peer that recognizes this notification may fail the exchange if
> the next CHILD_SA is doomed to fail.
In general, there's no way to know whether a CREATE_CHILD_SA exchange will succeed without trying it. The DH group seems to be rather small part of this: one peer could require using AES-256 for some traffic, but the other one could require something else.
If the policies are fundamentally incompatible (and changing them requires administrative action), I'm not sure if it's important to discover *this* particular incompatibility during IKE_SA creation (since most of the incompatibilities can't be discovered anyway at this time).
BTW, the chances of having mismatched policy probably depend on the user interface. If the UI offers exclusive options "(A) No PFS, (B) Group 2, (C) Group 5", it's easy to configure mismatched policies.
If the interface offered options "(1) Propose PFS with groups 2,5,X,Y (2) Require PFS with groups 2,5,X,Y -- fail connection if not supported by peer, (3) Don't propose PFS but accept if required by peer, (4) Prohibit PFS -- fail connection if required by peer", probably fewer people would choose "4" than would choose "A". (This is of course only a hypothesis, not confirmed by testing.)