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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
