[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Q: SA Bundles (again)
I've been dredging through the IPSEC mailing list archives to understand
SA bundles and tunnel mode vs transport mode in IKE transform proposals.
Dan Harkin's mail (included herein) was very helpful.
I have two more questions about IKE payloads and inbound IPSEC SA bundle
validation:
1. There was substantial discussion on the list about controlling
transport vs. tunnel mode when multiple protocols are contained in one
IKE proposal. (The consensus seemed to be that tunnel or transport
mode should be the _same_ for the proposal and for all of its protocols).
Does this agree with most implementations? For example, in the case of
the tunnel mode SA between H1 and SG (in the example discussed in the
attached mail), does most IKE implementations select (and expect) tunnel
mode in _both_ the ESP(des3 md5) and AH(sha1) transform payloads?
2. Dan commented about inbound SA verification in gateway SG:
"On the way back from h2 to h1 SG will see AH traffic and that'll
match the selectors for that SPD entry."
I'm confused about how H1 will verify inbound traffic against two
SA bundles (one to H1 and another to SG). For the moment, assume my
inbound IPSEC processing iteratively applies SA processing for each
SA selected by protocol and SPI. It records a list of those SA's
and eventually stops when it unwraps a non-IPSEC payload (such as TCP).
The set of SA's (from outermost to innermost) encountered by H1 when
processing a packet sent by H2 is:
SG->h1 AH(sha1)
SG->h1 ESP(des3,md5)
h2->h1 AH(md5)
h2->h1 ESP(blowfish,sha1)
Now that I've unwrapped the innermost payload (i.e. TCP), I look for
an SPD that covers H2 to H1 traffic. I'm _assuming_ that there are
_TWO_ SPD entries corresponding to the 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."
Those two SPD entries, in order, are:
src=h1, dst=h2, prot=AH -> tunnel(SG) ESP(des3 md5) AH(sha1)
src=h1, dst=h2, prot=ANY -> ESP(blowfish,sha1) AH(md5)
The inbound IPSEC engine must validate the SA's that were applied to the
packet by the sender. After applying four SA's to the packet, it uncovers
some transport protocol and then searches the SPD. It finds the rule:
src=h1, dst=h2, prot=ANY -> ESP(blowfish,sha1) AH(md5)
There are only _two_ SA's bound to this rule (ESP and AH) but the number
of SA's encountered by the packet during inbound processing was _four_.
==> Shouldn't the inbound IPSEC engine drop the packet because the
==> processing applied to it doesn't match the processing mandated
==> by the SPD?
How is this resolved? For example:
1. Should H1 have three SPD entries, two for outbound and one for inbound?
The inbound SPD entry lists all of the protocols contained in the two
outbound SPD entries.
2. Should I have just one SPD entry that creates two bundles? There
was some discussion on the list about single SPD entries that create
multiple IKE Phase 1 and 2 SA's to separate IPSEC peers.
(I personally prefer SPD entries that only address one other IPSEC peer
thus I much rather follow the implementation described in Dan's mail).
3. Should the implementation search the SPD after _every_ application
of an SA? If I did this, then we would get a match against the first
SPD entry after applying the first two SA's. (This completes the
processing of bundle between H1 and SG). Then, we empty the list of
processed SA's bound to the packet and continue processing. This
accumulates two more SA's for the bundle between H1 and H2.
Thanks,
Ben McCann
P.S. Where's Dan Harkins? His e-mail address at Cisco has been disabled.
Daniel Harkins wrote:
>
> 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.
--
Ben McCann Indus River Networks
31 Nagog Park
Acton, MA, 01720
email: bmccann@indusriver.com web: www.indusriver.com
phone: (978) 266-8140 fax: (978) 266-8111
--
Ben McCann Indus River Networks
31 Nagog Park
Acton, MA, 01720
email: bmccann@indusriver.com web: www.indusriver.com
phone: (978) 266-8140 fax: (978) 266-8111