Problem with IKE / IPSec in solaris

From: rbhasin@hss.hns.com
Date: Tue Apr 20 2004 - 01:59:59 EDT


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
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers



This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:28:29 EDT