Question on ISAKMP / PFS

[rsgamage1]

I'm seeing the following "Session disconnected" message on the the local PIX(7.0) VPN peer which has PFS (DH-Group 2) enabled.

Jun 20 15:36:52 192.168.1.1 Jun 20 2008 15:36:52 pix : %PIX-7-715077: Pitcher: received key delete msg, spi 0x85e0312a

Jun 20 15:36:52 192.168.1.1 Jun 20 2008 15:36:52 pix : %PIX-7-715077: Pitcher: received key delete msg, spi 0x60f647fd

Jun 20 15:36:52 192.168.1.1 Jun 20 2008 15:36:52 pix : %PIX-4-113019: Group = 181.168.1.49, Username = 181.168.1.49, IP = 181.168.1.49, Session disconnected. Session Type: IPSecLAN2LAN, Duration: 2h:15m:37s, Bytes xmt: 67640, Bytes rcv: 536552, Reason: User Requested

From RFC 2409, I've found the following with regard to PFS.

"Perfect Forward Secrecy (PFS) of both keying material and identities is possible with this protocol. By specifying a Diffie-Hellman group, and passing public values in KE payloads, ISAKMP peers can establish PFS of keys-- the identities would be protected by SKEYID_e from the ISAKMP SA and would therefore not be protected by PFS. If PFS of both keying material and identities is desired, an ISAKMP peer MUST establish only one non-ISAKMP security association (e.g. IPsec Security Association) per ISAKMP SA. PFS for keys and identities is accomplished by deleting the ISAKMP SA (and optionally issuing a DELETE message) upon establishment of the single non-ISAKMP SA. In this way a phase one negotiation is uniquely tied to a single phase two negotiation, and the ISAKMP SA established during phase one negotiation is never used again."

With this explanation does it mean that when PFS is enabled, ISAKMP rekeying cannot be done without deleting the session leading to a service disruption?

If at all possible, is there a way to avoid this disruption while PFS being activated?

Thank you for your time taken to explain this behavior.

[michael.leblanc]

I would interpret this as "each" of the two unidirectional IPSec SAs is negotiated via separate (perhaps non-concurrent) bi-directional ISAKMP SAs.

New IPSec SAs would be negotiated prior to expiration of the pre-existing SAs, and if no ISAKMP SA existed between the peers, one would be initiated/negotiated to facilitate a channel through which the IPSec SAs could be negotiated.

A tunnel can be up with established IPSec SAs, and traffic can traverse the tunnel in the absence of an ISAKMP SA, so I see no reason for a service disruption.

[ranilgamage]

However, it happens with this particular VPN where PFS is enabled.

This takes place in 2.25 hrs (3hr ISAKMP lifetime with a rekey margin) where it indicates the disconnected session(ref: original post).

What could be the reason then?

Thanks,

[michael.leblanc]

Are you actually experiencing service interruptions, or are you just expressing concern regarding messages that you have observed?

Were new IPSec SAs negotiated (to sustain the tunnel) prior to the deletion of the specific IPSec SAs referenced in the log messages (e.g.: "Pitcher: received key delete msg, spi 0x85e0312a"), or are you stating that no IPSec SAs remained after these were deleted, and that no ESP tunnel existed from that point forward?

On a PIX, is the "Session disconnected" message an acknowledgement that a pair of IPSec SAs are being deleted from the database, or that no IPsec SAs remain in the database for the specific peers?

If you are experiencing service interruptions, and you believe the cause relates to the use of PFS, I would remove the PFS parameter from the policy and attempt to prove whether it is or is not relevant.

I have PFS configured as part of IPSec policy (in the crypto map) for our IPSec + GRE tunnels, and do not see any service interruptions as a result. If PFS normally resulted in a service interruption, no one would be using it.

Would you explain what you mean when referring to a "rekey margin"? IOS is my reference point, and I'm not familiar with such a parameter.

[rsgamage1]

Yes, this is based on real experience, however it may not be directly related to PFS being activated.

It would be really appreciated, if you could explain what causes the "Session disconnected...Reason: User Requested" w.r.t. Site-to-site VPN using PIX.

New IPsec SAs are negotiated after the deletion of the ones referenced in the logs.

Well, the rekeying actually begins before a certain threshold period which is what I referred to as the rekey margin.

In this case the rekey-timer is actually 8100s which is 75% of the configured P1 lifetime(10800s).

Is there a better term for this? And any document written on the subject?