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

Re: Q about SA bundles

Whoa! Lets cool a bit, please! I didn't really mean to ask a change
into ISAKMP because of PFKEY v2 (I got carried away, sorry!). I just
happened to use PFKEY v2 and found it *so far* sufficient to express
the IPSEC needs, and wondered why ISAKMP appeared more complex than
necessary for that purpose [In which I may be in error, and the whole
reason for this debate is to find out.]

Let's take another start from another angle (which has already been
mentioned earlier by someone). Assume I have IPSEC that

 - is based on premise that the policy specification are unnegotiable
   and set by administration.

 - policy can specify any combination of AH, ESP and tunnels
   (currently no PCP, but I don't see any problems in adding another
   SA type for it).

 - it asks each SA independently via PFKEY v2 ACQUIRE message (and all
   that it expects, is that the unidirectional SA forms between the
   hosts on succesful negotiation; e.g. the transaction I have shown
   in previous messages).

For example, policy on H1 could be

"dst=h2" -> ESP(blowfish,sha1) AH(md5) tunnel(SG) ESP(des3 md5) AH(sha1) 
              <-----SA's with h2 ---->            <---SA's with SG - -->

Transforms applied to outgoing packet in the order they are listed
above. H2 would generate following independent ACQUIRE's:

   ACQUIRE: h1->h2 ESP(blowfish,sha1)
   ACQUIRE: h1->h2 AH(md5)
   ACQUIRE: h1->SG ESP(des3,md5)
   ACQUIRE: h1->SG AH(sha1)

The order of the ACQUIRE's is totally irrelevant to my IPSEC. The
packet can go out when all of them complete. With matching policies at
SG and H2, my version of IPSEC can verify that the required transforms
are done in the order as specified by the policy.  It does not need
any bundling support from the key management.

The question that now worries me:

   My implementation cannot communicate with other IPSEC
   implementations, because they require SAs to be negotiated in
   bundles by ISAKMP?

	(A side note: in above, I need to negotiate with H2 and SG. At
	H1 there is one bundle, but the bundles that SG and H2 see,
	are only subsets of it. So, In ISAKMP world, H1 needs to split
	the big bundle into two bundles?)

How do I solve this problem? Does ISAKMP allow me to generate SAs
individually, while other IPSEC still does the bundle checking
correctly (it should, there are lots of verbage in RFC-2401 about
checking the bundles while assuming totally random collection of SAs
in SAD; at least my implementation is done that way).

One more clarification: I don't have a key management implemented
myself, only the IPSEC kernel.

-- 
Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/
Follow-Ups: References: