On Mar 4, 2013, at 4:31 PM, Tero Kivinen <[email protected]> wrote: > Anoop V A (anova) writes: >> >> Hello experts, >> >> I have a generic doubt regarding the ISAKMP SA(phase 1) life time >> negotiation. My query is can we agree up on the ISAKMP life >> time in the first two messages of MM or AM. >> >> What I want to know is - the life time is sent as an proposal >> attribute in the first two messages of Main mode and aggressive >> mode. We are not negotiating the parameter so if the responder is >> having a less life time value configured - then can we transfer this >> info in the MM2 or AM2 message from the responder along with the >> negotiated proposal attributes. Basically I am trying to change the >> life time attribute sent by the initiator - in this scenario. > > Anything extra (notifications etc) you send inside the main mode or > agressive mode packets are not authenticated, so sending responder > life time notifications is not good idea (and the other end will > simply ignore it).
This is true for MM2, but not for MM6. MM6 is encrypted and authenticated, so the peer can and should (if they implemented the draft) use it. > >> We have the responder life time notify mechanism as per the draft >> (draft-ietf-ipsec-ike-lifetime-00), but the separate notify messages >> are not reliable in IKEv1(Uni directional) > > That is expired very old draft that did not get forward, there is no > point of implementing that... It makes sense for working with implementations where you can't configure such parameters, like VPN clients. Sadly, none of the generic IKEv1-using clients (like the L2TP clients) seem to support this draft. >> In short my questions are: >> >> 1. Can we send the responder life time notification in MM6 or >> AM2 message from the responder? > > You can, but most likely all implementations will ignore them, and > if any implementation does not ignore them, that opens attack where > attacker can shorten the lifetime at will by just adding such > notification. MM6 and AM2 are protected. > >> 2. Or can we alter the life time attribute of the ISAKMP SA >> proposal offer?( Is this considers as a violation of the >> RFC) > > That is considered violation of the RFC, thus all complient > implemnetations will reject the proposal. RFC2408 section 4.2 Security > Association Establishment last paragraph: > > The > initiator MUST verify that the Security Association payload received > from the responder matches one of the proposals sent initially. > > Easy answer to all of your questions is to NOT use the protocol that > was obsoleted more than 7 years ago (IKEv1 was obsoleted by IKEv2 in > 2005), and instead start to use current version of the protocol i.e > IKEv2, which already solves those problem (the notifications are > authenticated, the lifetimes are removed and moved to local matter, > the informational exchanges are reliable etc). Now that I agree with. This draft addresses one deficiency in IKEv1. The reason to support IKEv1 today is to support legacy implementations. I don't think anyone is adding this feature now to legacy implementations. So yes, <hat type="vendor"> Check Point code supports it, but </hat> it's better to use IKEv2 where interoperability with different configured lifetimes has been shown to work. Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
