Let me draw a time-sequence diagram to explain things as I understand
them (fixed-width font alert)
site to site policy
policy: 1.0.0.0/8 <-> 2.0.0.0/8
Alice-GW Bob-GW
--Trigger--> (1.2.3.4->2.3.4.5)
(1) <====IKEv2 exchange 1==>
<***Trigger**IPsec SA**>
(2) <====IKEv2 rekey ======>
<***second***IPsec SA**>
(3) "POLICY CHANGE"
(4) <====IKEv2 rekey: fail=>
(5) new trigger (1.2.3.4 -> 2.3.4.5)
(6) <====IKEv2 exchange 1==>
<***third***IPsec SA***>
1.2.3.4/32 <-> 2.0.0.0/8
The question is, what was this policy change at (3)?
Shouldn't such a policy change have caused any incompatible SAs to be
removed? Let me suggest that perhaps there are changes which are not
clearly policy changes.
Postulate that Bob-GW also has a "road-warrior" (George) that normally
lives at Alice's site.
Normally, George lives behind Alice-GW, and uses the site to site
tunnel. When George is on the road, he uses his 1.0.0.0/8 address
(which is 1.4.5.6) (He may also bring up a tunnel with Alice-GW)
Let's say that the event at (3) is that George brought up his tunnel
with Bob-GW. Bob now has two SAs in his SPD:
1. src: 2.0.0.0/8 dst: 1.4.5.6/32 STUFF.
2. src: 2.0.0.0/8 dst: 1.0.0.0/8 STUFF.
The SPD is nicely ordered, so traffic to George travels down the
seperate tunnel, while traffic back to Alice-site uses the original
tunnel. The George tunnel had to be inserted before #2 so that it would
have higher priority.
Now, when Alice rekeys, is that site allowed to assert control over
George's traffic? There are many answers here. I think that there are
arguments for many things.
Note that in this situation, (3) is not a policy change from an
administrative point of view, but simply George bringing up his tunnel.
The IP address 1.4.5.6 might not even be present in the PAD: it could
come from a certificate.
Note that I am not saying that that the situation outlined above
(whereby Bob-GW fails the rekey, forcing Alice-GW to try again when she
has a trigger packet, resulting in a much narrower SA -- how narrow is
up to Bob-GW) is correct.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
