Hi Martin, as we know specs are the one side and Cisco is the other side...
One could argue that the " ISAKMP SA that was used to secure the request" does not expire, but is renewed, also I am aware that this is not the strict interpretation. Since the rekeying fails in the mode_config state, I would like to test, if it goes through if we do not request a new ip. Is there any chance in the xauth/mode_config code to distinguish between an initial key exchange and a rekeying. If yes, how? If you could give me a hint, I would create a patch and see if this changes anything. Thanks & Regards Gerald > -----Ursprüngliche Nachricht----- > Von: Martin Willi [mailto:[email protected]] > Gesendet: Dienstag, 12. März 2013 10:09 > An: Gerald Richter - ECOS > Cc: [email protected] > Betreff: Re: AW: [strongSwan] Aggressive Mode. Rekeying fails > > Hi Gerald, > > > The IKE Rekeying succeeds, but afterwards it gets stuck within a > > mode_config request. I don't think there should be a mode_config > > request during rekeying or I am wrong? > > strongSwan binds an INTERNAL_IPx_ADDRESS to the ISAKMP_SA, so it valid > only during the lifetime of an ISAKMP_SA. This implies that IKE rekeying (or > better, re-authentication) re-negotiates virtual IPs. > > It is not fully clear to me what is the correct behavior, but > draft-dukes-ike-mode-cfg-02 says: > > > The requested address is valid until the expiry time defined with the > > INTERNAL_ADDRESS EXPIRY attribute or until the ISAKMP SA that was used > > to secure the request expires. > > Regards > Martin _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
