[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IPSec SA DELETE in "dangling" implementation

Andrew Krywaniuk writes:
> > If there is no traffic going on the SA then there is no need to rekey
> > it. This also means that the IPsec SA can only expire because of the
> > seconds limit. This means that the other end has the same lifetime
> > information, thus it is going to expire it at the same time. No
> > problem there.
> 
> I don't think it's fair to assume the other end has the same lifetime
> information. Sending lifetime notifies isn't required and parsing them (and
> obeying them) is not a MUST.

If I am a initiator and said, that I am going to use this lifetime,
and the other end does not trust me, it is his problem. If I am a
responder and I send responder lifetime notification, and he doesn't
trust that either, that is again his problem.

It is not a MUST to trust delete payloads either. The ISAKMP RFC says
that you are allowed to ignore the delete payloads, they are only sent
to inform you that the other end deleted his SA. You don't need to act
based on that information if you dont like.

If the other ends implementation is broken, I really don't care if he
keeps few extra SAs up and running for too long. 

> If YOU continue to send traffic on an SA that I have expired, that would
> still be a violation of MY security policy. In order to force the other side
> to cooperate, we have to send the deletes (unless parsing and obeying
> lifetime notifies is required).

Even if you send delete payloads, that does NOT mean that the other
end still cannot send you packets. It is allowed in the RFC to keep
sending packets using the old SPI. Sending delete means that you are
saying to the other end that IF they still continue sending packets to
you using that SPI, you will drop them.

There is NO way to force the other end not to cooperate.

> The point here is that if I want to be sure that my security policy is
> enforced then I must send the delete. If I hang up without sending the
> delete then it's my own fault (I am defeating my own security policy).

If the other end ignores all the delete payloads (as it is allowed to
do), how that is going to enforce your policy? 

> And just as an afterthought: if anyone did want to attempt to hijack your
> session undetected, after you've hung up would be the best time.

If somebody is able to hijack my session, he would also be able to
read everything I sent using that session. I do not plan to use that
weak security parameters to allow that. We are supposed to make the
even the reading of the material almost impossible and doing real time
breaking of the IPsec should be much harder.

Anyways sending deletes does not help here at all, because the
attacker can simply delete those packets (or respond to them if he
broke the Diffie-Hellman).

Anyways I don't think that is very valid point. You MUST set your
lifetime low enough, so it will remove this kind of possiblity.
Whether or not you send delete payloads changes that thing. 
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
References: