No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade
Knowledge Base

FAQ-Why IKE Module of AR Router Reports Invalid Cookie and Discards IKE SA Packet

Publication Date:  2012-07-27  |   Views:  4  |   Downloads:  0  |   Author:  Chen Tao  |   Document ID:  EKB0000244832

Contents

Issue Description

Q:
AR connects Ipsec with the router of C enterprise, why IKE module of AR router reports "Invalid Cookie" and discards IKE SA packet and there is "no SA" alarm information on the router of C enterprise?

Alarm Information

Null

Handling Process

A:
I  AR router has the following alarm information:
%Aug 19 12:06:43:726 2006 WANGJING10F_AR46 IKE/4/DROP:
IKE packet dropped: (src addr: 10.4.212.66, dst addr: 10.4.79.222) with I_Cookie cf845bb726b6fefe and R_Cookie 1947e95b06a91a29, because of ' Invalid cookie ' from payload ISAKMP HEADER
%Aug 20 09:42:44:382 2006 WANGJING10F_AR46 IKE/4/DROP:
IKE packet dropped: (src addr: 10.4.212.66, dst addr: 10.4.79.222) with I_Cookie ec7f8b23c8b3eb0d and R_Cookie 1947e95ba81b7f7a, because of ' Invalid cookie ' from payload ISAKMP HEADER
There is the following alarm information on the router of C enterprise:
Aug 27 22:30:43.304 CST: %CRYPTO-4-IKMP_NO_SA: IKE message from 10.4.212.66 has no SA and is not an initialization offer
Aug 28 20:06:43.241 CST: %CRYPTO-4-IKMP_NO_SA: IKE message from 10.4.212.66 has no SA and is not an initialization offer
II. Analyze debug information of AR46 and that of CISCO. The problem occurs in the handling of notifying information after the negotiation of the first period (IKE SA negotiation) and it is not related with the negotiation in the second period (IPsec SA negotiation). The conclusion is as follows: 
1. IKE report of AR46 “"nvalid Cookie" and discard packet. After the negotiation of the first period is finished, both sides update IKE_SA. When CISCO clears old IKE_SA, it sends notification of SA delete to AR46; but CISCO device does not use updated Cookie of IKE_SA. It uses old Cookie of IKE_SA (CISCO notifies deleted IKE_SA to AR46.). When AR46 receives deleted information, it clears old IKE_SA and informs that Cookie has no matching IKE_SA at AR46. Our device IKE reports "Invalid Cookie". 
Namely, if CISCO uses negotiated Cookie of IKE_SA to communicate, there is no such problem. It is proper to use negotiated Cookie of IKE_SA because old IKE_SA is outdated. 
2. CISCO reports "has no SA". After AR46 discards deleted information of CISCO, it sends "Drop" notification packet to CISCO. But AR46 cannot find usable IKE_SA through Cookie of received deleted information of CISCO. AR46 recreates ICOOKIE (RCOOKIE is 0.) as Cookie of "Drop" notification packet. When CISCO receives it, it reports "has no SA".
For the use of notification of IKE, there is difference between AR46 and Cisco device. Both sides update IKE_SA through IKE negotiation and delete outdated IKE_SA. The problem does not influence the operation of the system.
3. Why the interval of IKE alarm is about 21 hours and 36 minutes?
Under default, the living period of ISAKMP SA is 86,400 seconds (24 hours).
In order to ensure the continuity of IPSEC traffic, mature IPSEC system starts IKE negotiation in advance (It is also called "soft timeout" that RFC advises.). "Soft timeout" of AR router is 90% of living period, 21 hours and 36 minutes. 

Root Cause

Null

Suggestions

Null