Michael Richardson writes:
> 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.
Which means now that traffic from tunnel from Alice having 1.4.5.6
address MUST be dropped as it is coming from wrong tunnel, as there is
higher priority SPD entry which says they should be coming from the
other SA. For me that would mean that SPD entry #2 is bad as now not
all traffic covered by the traffic selectors are not allowed to be
sent over that SA (meaning it will cause black hole if Alice tries
to send traffic using those addresses).
Thus the decorrelated version of the SPD would be:
1. src: 2.0.0.0/8 dst: 1.4.5.6/32 STUFF.
2a. src: 2.0.0.0/8 dst: 1.0.0.0 - 1.4.5.5 STUFF.
2b. src: 2.0.0.0/8 dst: 1.4.5.7 - 1.255.255.255 STUFF.
Hmm... now reading RFC4301 I found out that it says you are allowed to
create such entries, as it says you can either
a) send decorrelated entries as traffic selectors
b) send original entry from correlated SPD
c) send subset of decorrelated entries.
(RFC 4301 section 4.4.1 under decorrelation).
thus during rekey you can still rekey the original 1.0.0.0/8 <->
2.0.0.0/8 tunnel and that should not change anything as the first SPD
entry is still there with higher priority as #2 has.
It also says something about the handling changes to the SPD:
----------------------------------------------------------------------
Handling Changes to the SPD While the System Is Running
If a change is made to the SPD while the system is running, a
check SHOULD be made of the effect of this change on extant SAs.
An implementation SHOULD check the impact of an SPD change on
extant SAs and SHOULD provide a user/administrator with a
mechanism for configuring what actions to take, e.g., delete an
affected SA, allow an affected SA to continue unchanged, etc.
----------------------------------------------------------------------
Which would indicate that RFC4301 does not actually require you to
remove SAs which violate your own policy (which I did expect it to
do). I.e. you can still keep SAs even when you know that some traffic
coming from those SAs will be thrown away immediately when you do
inbound traffic checks as the traffic selectors negotiatiated for the
SA do not match the SPD entries.
> 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.
If it results change to the SPD, I would consider that as a policy
change, regardless of the reason of the change.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
