Re: [IPsec] Regarding ISAKMP SA lifetime negotiation.

[Paul Wouters <[e-mail]>]

On Tue, 5 Mar 2013, Tero Kivinen wrote:

> As I pointed out earlier, attacker can MODIFY the notification data,
> so they can change the life time stored inside the notification data
> (there are some difficulties there, but lets not go to them). On the
> other hand you would never accept any lifetime that would not be
> accordingly to your own policy anyways, so this attack isn't that
> effective in this case, as attacker can only change lifetime to
> something that you would otherwise accept. So in worst case you are in
> the same situation you were without this notification.
>
>> I understand may be other implementation will avoid this extra
>> notify - but is there any violation in sending this extra notify in
>> these messages?
>
> Most likely they will ignore the extra notify, but to be safe it might
> be better to add vendor id payloads and only send notify if the other
> end is sending known vendor id. There are some quite bad IKEv1
> implementations out there, and I would not even try to guess what they
> might do when they get extra notification payloads.

I already see some different vendorids for this coming in at times.

The openswan/libreswan implementations ignore this vid, however I have
been thinking about trying to make use of it on the initiator. It is
useful if the responder is set to never rekey. If you don't take their
lifetime into account, the IPsec SA can silently die (Cisco does this to me)
if their lifetime is shorter. Or the remote could send a Delete/Notify and
then the tunnel could be briefly down while the initiator re-initiates.

The work around now is to ensure to set the keylife shorter on the
initiator so you avoid these issues, but that requires manual and per
case configuration.

Paul