[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Q about SA bundles
On Fri, 22 Jan 1999 21:17:07 +0200 Markku Savela wrote
>
> 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.
As the Prime Minister says during Prime Minister's Question Time, "I refer
the Right Honourable Gentleman to the comments I made some moments ago".
Specificially, those in 199901221728.JAA10408@chip.cisco.com.
> 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?)
Actually there are 2 bundles here. One is AH and ESP protecting traffic
from h1 to h2, with destination h2, and another of AH and ESP protecting AH
(since that'll be the protocol of the packet as it comes by) from h1 to h2,
with destination SG.
SG can't have policy with selectors identifying traffic from h1 to h2
because it won't be able to look into the packet to identify that traffic.
Also there's no mechanism to inform SG of the SPI chosen by h2 to use to
protect this traffic. SG must have selectors for AH from h1 to h2. Since
you're assuming identical configs on each side h1 must also have selectors
to identify AH traffic to h2 for bundle #2. The selectors on h1 have to
be different for each bundle.
The way this works in our implementation is that the packet from h1 to h2
triggers an IKE negotiation to h2 to negotiate bundle #1. Depending on
policy (whether h1 and SG say that IKE traffic to h2 must also be IPSec
protected with the rest of the h1->h2 traffic) that may trigger another IKE
exchange with SG for bundle #2. If it doesn't, if IKE can go in the clear,
then the IKE exchange for bundle #2 is triggered by the first IPSec protected
packet from h1 to h2, which will have a protocol of AH. Once the 2nd IKE
exchange is finished the nested tunnels are formed and everything works. On
the way back from h2 to h1 SG will see AH traffic and that'll match the
selectors for that SPD entry.
> 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).
You can generate them one at a time and IKE will express them as atomic units
but as I said I think your implementation will have trouble talking to other
implementations sometimes.
> One more clarification: I don't have a key management implemented
> myself, only the IPSEC kernel.
We have key management and also IPSec and nested tunnels with bundled SAs--
what you described above-- work just fine. Of course, we're not using PFKEYv2
and, therefore, are not restricted to individual, non-conjunctive, ACQUIREs.
Dan.
Follow-Ups:
References: