|Main Archive Page > Month Archives > ipsec archives|
Does this still leave a true IKEv2 protocol problem for environments which wish to configure separate DH groups for IKE and IPsec SAs and also have reasons (NAT / remote-access) to configure the peers as initiator/responder only?
If the answer is "if you need to configure initiator/responder only
then you have to adminstrativly ensure that your PFS policy uses the
same DH group for both IKE and
IPsec" that would be fine (with me). I'm just not yet clear if that is what you are saying.
My basic question is... Do I have to write documentation guidance to adminstrators of my systems for this?
> -----Original Message-----
> From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
> Sent: Sunday, November 18, 2007 11:52 PM
> To: email@example.com; firstname.lastname@example.org
> Subject: RE: [IPsec] CHILD_SA and PFS
> If the initial handshakes have completed, the peers have at least
> one Diffie-Hellman group they both support and consider acceptable.
> Although in theory you could consider group X acceptable only
> for "phase 1", but not "phase 2", this sounds like a somewhat
> weird policy to me.
> About the "PFS mode": if the exchange initiator proposes a DH
> group in CREATE_CHILD_SA exchange, I'd usually expect the
> responder to accept it (if the group is generally acceptable),
> even if the responder doesn't care about PFS. If the initiator
> doesn't propose a DH group, and the responder cares about PFS,
> the responder can always initiate rekeying itself.
> Best regards,
> > -----Original Message-----
> > From: ext Chinh Nguyen [mailto:email@example.com]
> > Sent: 16 November, 2007 18:14
> > To: firstname.lastname@example.org
> > Subject: [IPsec] CHILD_SA and PFS
> > As stated in RFC4718, we do not include a DH group in the first
> > CHILD_SA's proposals, due to the fact that no KE payloads are
> > exchanged. This leaves the situation that any mismatch in the "PFS"
> > mode of the peers (on/off) or DH group will not be known until the
> > ipsec SA rekeys. At which time, presumably a NO PROPOSAL CHOSEN
> > will be sent back.
> > However, from a VPN user's perspective, it's not clear which is the
> > more palatable scenario: failure to login (assuming we send the DH
> > group in SAi2) or failure to maintain a VPN session (ipsec rekey
> > fails).
> > Chinh
> > --
> > http://www.certicom.com
> IPsec mailing list