[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bundles, policies, tunneling, ordering etc...
"Michael C. Richardson" <mcr@sandelman.ottawa.on.ca> wondered
privately if the reason I don't have any ordering requirements at the
IKE level, is that I only have one transform at other end.
The example chosen is represents fairly complex situation, and adding
more transforms between h1-sg2 or h1-h2 would still not change the
basic idea. However, to demonstrate, I will collapse my example into
case where for some odd reason sg2==h2, the picture simplifies
into
+============================+
| |
| +========================+ |
| | | |
| | | |
H1* ---- (Internet) ------|SG2* --- (local) --- H3*
Might be seen as situation to occur when a remote admin wants to
configure the SG2, or some general service happens to be on the SG2.
I'm leaving in the tunnels. Thus, the 'h1' side processing doesn't
change at all at IPSEC level. The change may affect key management, if
it wants to *optimize* the negotiation when it notices that H2==SG2,
by doing it with single exchange instead of two independent exchanges.
I think the policies below start to approach a real life situation
where a client is on the road, and needs to connect to the company
network. Identification of the client cannot be based on IP address,
but on something that it gets from the policy definition via ACQUIRE
(for example, one could configure some user name as Identity into the
policy to be passed in ACQUIRE), or it could be just something that
the client key management knows from the environment (current user of
the portable).
----------------------------------------------------------------
Policies: Selector => Bundle
@H1: H1<->local => ESP(3des,sha1), AH(sha1,tunnel=SG2)
@SG2: SG2<->internet => ESP(3des,sha1), AH(sha1,tunnel=H1)
local<->internet => AH(sha1)
@H3: H2<->H1 => ESP(3des,sha1)
Comment:H3 is left as an example to remind that this new
configuration is just an extension of my previous example. In
above, it is assumed tha 'local', in addition to H3, matches
also 'SG2', to simplify the policy.
===== Setting up the SA's ===========================
-- If initiator is H1, and tries to send a packet to SG2 --
1. the packet matches the h1<->local selector at H1, no matching SA's
exist yet.
2. IPSEC sends two independent ACQUIRE requests
AQ1. ACQUIRE ESP src=h1 dst=sg2, proposal=(3des,sha1)
AQ2. ACQUIRE AH src=h1 dst=sg2, proposal=(sha1)
3. Key management of AQ1
at h1: GETSPI ESP dst=h1 => SA1(ESP,SPI1,h1)
at sg2: GETSPI ESP dst=sg2 => SA2(ESP,SPI2,sg2)
ADD SA1(3des,sha1)
UPDATE SA2(3des,sha1)
at h1: ADD SA2(3des,sha1)
UPDATE SA1(3des,sha1)
4. Key management of AQ2
at h1: GETSPI AH dst=h1 => SA3(AH,SPI3,h1)
at sg2: GETSPI AH dst=sg2 => SA4(AH,SPI4,sg2)
ADD SA3(sha1)
UPDATE SA4(sha1)
at h1: ADD SA4(sha1)
UPDATE SA3(sha1)
Comment: negotiation doesn't have o care about the
order of AH and ESP!!
-- If initiator is SG2, trying to send packet to H1 --
1. the packet matches sg2<->internet selector at H1, no matching SA's exist
yet.
2. IPSEC at sg2 sends two independent ACQUIRE requests
AQ1. ACQUIRE ESP src=sg2 dst=h1, proposal=(3des,sha1)
AQ2. ACQUIRE AH src=sg2 dst=h1, proposal=(sha1)
3. Key management of AQ1
at sg2: GETSPI ESP dst=sg2 => SA2(ESP, SPI2, sg2)
at h1: GETSPI ESP dst=h1 => SA1(ESP, SPI1, h1)
ADD SA2(3des,sha1)
UPDATE SA1(3des,sha1)
at sg2: ADD SA1(3des,sha1)
UPDATE SA2(3des,sha1)
2. Key management of AQ2
at sg2: GETSPI AH dst=sg2 => SA4(AH, SPI4, sg2)
at h1: GETSPI AH dst=h1 => SA3(AH, SPI3, h1)
ADD SA4(sha1)
UPDATE SA3(sha1)
at sg2: ADD SA3(sha1)
UPDATE SA4(sha1)
-- In either case, the end result of SA's is --
@H1 @SG2
SA1 <---- SA1
SA2 ----> SA2
SA3 <---- SA3
SA4 ----> SA4
====== Excanging IPSEC packets ==========================
-- A packet from H1 to SG2 --
@H1 starts with [IP h1->sg2][data]
1. h1->sg2 matches the SPD bundle in above,
1st bundle item matches SA2 (apply ESP)
-> [IP h1->sg2][ESP]
2nd bundle item specifies a tunnel, apply
-> [IP h1->sg2][IP h1->sg2][ESP]
2nd bundle item matches SA4 (apply AH)
-> [IP h1->sg2][AH][IP h1->sg2][ESP]
@SG2 receives [IP h1->sg2][AH][IP h1->sg2][ESP]
1. SPI of AH selects SA4, applying unwraps AH
-> [IP h1->sg2][IP h1->sg2][ESP]
processes the IP in IP, and finds it for me again
-> [IP h1->sg2][ESP]
2. SPI of ESP selects SA2, applying unwraps ESP
-> [IP h1->sg2][data]
3. Policy bundle check: h1->sg2 matches the SPD entry with two
bundle items, the first should match SA2 (ESP) and second should
match SA4 (AH)
-- A packet from SG2 to H1 --
@SG2, starts with [IP sg2->h1][data]
1. sg2->h1 matches the SPD selector (sg2<->h1)
1st bundle item matches SA1 (apply ESP)
-> [IP sg2->h1][ESP]
2nd bundle item specifies a tunnel, apply first
-> [IP sg2->h1][IP sg2->h1][ESP]
2nd bundle item matches SA3 (apply AH)
-> [IP sg2->h1][AH][IP sg2->h1][ESP]
@H1 receives [IP sg2->h1][AH][IP sg2->h1][ESP]
1. SPI of AH selects SA3, applying unwraps AH
-> [IP sg2->h1][IP sg2->h1][ESP]
revealing a tunnel to h1, unwrapped
-> [IP sg2->h1][ESP]
2. SPI of ESP selects SA1, applying unwraps ESP
-> [IP sg2->h1][data]
3. Policy bundle check: sg2->h1 matches the SPD entry with two
bundle items, the first should match SA1 (ESP) and second should
match SA3 (AH), can also check that the original src at AH step
matches the tunnel in bundle (sg2).
-------------
--
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/
References: