[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bundles, policies, tunneling, ordering etc...
> consider the case4 (in Page 27) from H2
> +==================================================+
> | |
> | +========================+ |
> | | | |
> | | | |
> H1* ---- (Internet) ------|SG2* ---- (Local ----- H2*|
> .
>
> H1 must have TWO individual IN-BOUND policies H2-SG2 and H2-H1.
Not in my world. H1 has a single policy entry mapping h1->h2 traffic
into two bundle items as follows,
selector H1->H2 => ESP(3des,sha1), AH(sha1,tunnel=SG2)
The following long and tedious ananlysis attemps to explain my view of
this and why I still don't see the reason for all this worry about
ordering in the key management. The order is defined by the policies
similar to above, and there is no need to make key management
unnecessarily comlex by worrying about ordering. Key management should
just negotiate each SA pair independently (AQ1 and AQ2 below). KISS
principle. This a view from kernel IPSEC/PFKEY to the IKE/ISAKMP, what
I expect the key management to achieve.
The text below is rather hard to read, but I cannot find a simpler way
to express the detail I want. I'm presenting it in hope of someone
pointing the flaws in it, if any, because to me this appears to be a
workable scenario and this is how my version of IPSEC assumes it to
work. If there are flaws, I need to fix something.
----------------------------------------------------------------
Policies: Selector => Bundle
@H1: H1<->H2 => ESP(3des,sha1), AH(sha1,tunnel=SG2)
@SG2: local<->internet => AH(sha1)
@H2: H2<->H1 => ESP(3des,sha1)
===== Setting up the SA's ===========================
-- If initiator is H1, and tries to send a packet to H2 --
1. the packet matches the h1<->h2 selector at H1, no matching SA's
exist yet.
2. IPSEC sends two independent ACQUIRE requests
AQ1. ACQUIRE ESP src=h1 dst=h2, 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 h2: GETSPI ESP dst=h2 => SA2(ESP,SPI2,h2)
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 H2, trying to send packet to H1 --
1. the packet matches h2<->h1 selector at H1, no matching SA's exist
yet.
2. IPSEC at h2 sends ONE ACQUIRE
AQ1. ACQUIRE ESP src=h2 dst=h1, proposal=(3des,sha1)
3. Key management of AQ1
at h2: GETSPI ESP dst=h2 => SA2(ESP, SPI2, h2)
at h1: GETSPI ESP dst=h1 => SA1(ESP, SPI1, h1)
ADD SA2(3des,sha1)
UPDATE SA1(3des,sha1)
at h2: ADD SA1(3des,sha1)
UPDATE SA2(3des,sha1)
After this H2 is ready to send the packet, which hits SG2
1. the packet matches the local<->interent selector at SG2, no
matching SA's exist yet.
2. IPSEC at sg2 sends ONE ACQUIRE
AQ2. ACQUIRE AH src=sg2 dst=h1, proposal=(sha1) [?proxy=h2]
3. 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 @H2
SA1 <------------ SA1
SA2 ------------> SA2
SA3 <---- SA3
SA4 ----> SA4
====== Excanging IPSEC packets ==========================
-- A packet from H1 to H2 --
@H1 starts with [IP h1->h2][data]
1. h1->h2 matches the SPD bundle in above,
1st bundle item matches SA2 (apply ESP)
-> [IP h1->h2][ESP]
2nd bundle item specifies a tunnel, apply
-> [IP h1->sg2][IP h1->h2][ESP]
2nd bundle item matches SA4 (apply AH)
-> [IP h1->sg2][AH][IP h1->h2][ESP]
@SG2 receives [IP h1->sg2][AH][IP h1->h2][ESP]
1. SPI of AH selects SA4, applying unwraps AH
-> [IP h1->sg2][IP h1->h2][ESP]
processes the IP in IP
-> [IP h1->h2][ESP]
2. Policy bundle check: (h1->h2) matches the
the local<->internet selector in SPD, the
SA4 fits the bundle spec for incoming
direction.
3. Forward [IP h1->h2][ESP] to local
@H2 receives [IP h1->h2][ESP]
1. SPI of ESP selects SA2, applying unwraps ESP
-> [IP h1->h2][data]
2. Policy bundle check: (h1->h2) matches the
h2<->h1 selector in SPD, the SA2 fits the
bundle spec for incoming direction.
-- A packet from H2 to H1 --
@H2, starts with [IP h2->h1][data]
1. h2->h1 matches the SPD selector (h2<->h1)
The only bundle item matches SA1 (apply ESP)
-> [IP h1->h2][ESP]
2. send packet to local net (assumed that the normal routing will
get it to the SG2. If that is not the case, it may need to be
wrapped by a "bare" tunnel to SG2, but this is outside IPSEC)
@SG2 receives [IP h2->h1][ESP]
1. h2->h1 matches the SPD selector (local<->internet)
The only bundle item matches SA3, but because the source address
is H2 and not SG2, it needs to add a tunnel wrapping first
-> [IP sg2->h1][IP h2->h1][ESP]
and after this, it can apply the AH
-> [IP sg2->h1][AH][IP h2->h1][ESP]
Comment: this "implicit tunnel insertion" is not explicit in
documents, but it seems that a very mechanical rule can be
applied before processing of AH or ESP transforms:
"If the src of the IP packet is not current host, then add
a tunnel wrapping [src=current host, dst=original dest]"
Could also get this explicity by having a special tunnel
flag in the SPD entry requesting the transformation.
2. send packet to internet (as this step didn't involve any IPSEC
on receive side, no policy bundle checks are needed)
@H1 receives [IP sg2->h1][AH][IP h2->h1][ESP]
1. SPI of AH selects SA3, applying unwraps AH
-> [IP sg2->h1][IP h2->h1][ESP]
revealing a tunnel to h1, unwrapped
-> [IP h2->h1][ESP]
2. SPI of ESP selects SA1, applying unwraps ESP
-> [IP h2->h1][data]
3. Policy bundle check: h2->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).
-------------
Comments?
--
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: