Problem with IKE / IPSec in solaris

rbhasin at hss.hns.com rbhasin at hss.hns.com
Tue Apr 20 01:59:59 EDT 2004


Hi,

We are facing problems while using the IPSEC features of Solaris 9, the 
details are captured below.

Problem Statement and Description (using Solaris IKE/IPSec feature):
The application scenario is as described below:

1. We have a TCP client connection with a peer application, which is a TCP 
server. This connection is secured using IKE/IPSEC features provided by 
Solaris.

2. The number of messages being exchanged on this TCP connection is medium 
- say approximately  3 messages per second in either direction.

3. The problem we are facing is that after the expiry of the existing 
IPSEC SAs, IKE Daemon on the respective application (local as well as 
peer) happen to originate Quick Modes to re-establish IPSEC SAs, which 
leads to formation of multiple SAs. One more critical obervation here is 
that multiple QUICK Mode messages get exchanged at this point (sometimes 
up to 24 leading to 8 IPSEC SAs creation), where as in a normal scenario, 
three messages should be exhcnaged in all from the respective peers to 
establish one new IPSEC SA. 

Thus because of the large number of Quick Mode messages being exchanged, 
there is a substantial amount of time ( up to 10 seconds ) for 
which no messages are sent on this TCP connection. This delay causes lots 
of problems at the application which is using this TCP connection to 
exchange application-level messages.

Important Implementation Hint as per protocol:
As per SECTION 9 of RFC 2409, one possible solution to solve this problem 
is to have periodic establishment of IPSEC SAs instead of on-demand 
creation, i.e., triggering Quick mode inside IKE Daemon of Solaris, before 
the expiry of existing SAs (here it is assumed that Phase 1 ISAKMP SA is 
still alive). 

Query:
Hence the question boils down to the fact that is there a way by which the 
application can trigger the Solaris IKE daemon to start the next Quick 
mode so that new IPSEC SA can be created before the expiry of existing old 
ones, inline with Section 9 of RFC 2409?

Any ideas to resolve this would be highly appreciated.

Thanx in Advance

Regds,
- Rajan



More information about the sunmanagers mailing list