Yoav Nir writes:
> The traffic selectors in the REKEY exchange are not currently
> specified. If were designing IKEv2 from scratch, I would be in favor
> of removing traffic selectors altogether from REKEY exchanges - I
> don't think it should be called a "rekey" if you get a totally
> different SA. This does raise the question (that has been asked
> before) of why do we really need REKEY_SA exchanges as opposed to
> regular exchanges.
I think the reason for REKEY_SA is to know which SA is being replaced
with the one we are creating now. I.e. from where we can move
statistics to, and from which SA we should move traffic to this new SA
(even before the old SA expires, but after we know other end has also
installed the SAs, i.e. after responder sees traffic in the new
incoming SA).
For example in our implementation rekeyed SA shares same internal SA
slot in the engine, i.e. we have one SA slot having two associated
crypto contextes and SPIs, and only one of them are in active use.
I.e. old one is in use until traffic moves to new one and then later
the old ones are removed (but might still be used to decrypt traffic
as there might be out of order packets coming in) etc. I.e. it makes
implementations easier and more efficient when you know which SA is
going to be replaced with the rekey.
In IKEv1 you usually tried to do same by inspecting the selectors and
tried to guess which one was the old SA being replaced. This is not
possible in IKEv2, as it is normal to have multiple overlapping Child
SAs with same selectors for different QoS classes.
> As it is, I think the initiator of the rekey (not necessarily the
> same as the initiator of the old SA) should keep the selectors in
> the old SA, and the responder should either accept of reject, but I
> don't think we need to capitalize the SHOULD.
Responder should do normal narrowing of the selectors, it should not
ever reject the selectors. I mean if the selectors initiator offered
is superset of the old selectors of the SA, they cannot be against the
policy of the responder, thus the responder should either accept wider
ones or narrow it down to subset of the offered selectors as normally.
> In some implementations, the REKEY is generated because of traffic
> passing the IPsec stack when little time remains before the child SA
> expiration. It may be much more convenient to rekey with the
> narrowed selectors rather than locating an SPD entry which is a
> superset of the SPD cache entry that matches this SA.
I agree that should be allowed, but in most cases the implementations
do have pointers back to the original SPD entry anyways, and in that
case they SHOULD use the original selectors from the SPD entry if they
are readily available.
> I think the rekey initiator SHOULD propose any superset of the
> current selectors, which can be the current selectors, or anything
> that matches its policy.
Yes.
> I don't think we should recommend doing one or the other.
I would prefer to say "SHOULD" for the selectors from the original SPD
entry, but I can accept also the wording saying that either one can be
used.
> We can and should, however, require the responder to not expect the
> traffic selectors in a rekey-SA to exactly match those of the
> current SA.
Yes, this is something we should at least require (even as MUST).
Now that I think more of this I think the initiators proposed
selectors MUST always be same or superset of the old SAs selectors.
They cannot be narrower than what was used before, as that would
normally mean that the policy of the inititor was changed so that old
SA is no longer valid with the new policy, which means it should be
deleted and new SA created (and this is so rare case, that we do not
need to optimize performance for this). Earlier I though we could use
rekey in that case too, but I think it is better to say it MUST be
same or superset of the currently used selectors.
The responder should narrow the offered proposal down to either
superset of the current used selectors, or same as currently used
selectors. Again it really cannot narrow it down to anything smaller
than currently used, as in that it case the current SA is against its
policy, and should be deleted.
If we go with those rules (i.e. SA can be rekeyed only to superset of
the current SA, never to subset), then we actually do NOT need the
specific selectors from the packet, as we always know that the subset
where we need to narrow it down to, is the one containing the old SAs
selectors.
So perhaps we should change the resolution to issue #12 (and #11):
----------------------------------------------------------------------
- When initiator proposes traffic selectors when rekeying Child SA,
the proposed traffic selectors SHOULD be either superset of the
traffic selectors used in the Child SA (i.e. come from the
currently active (decorrelated) policy), or same as the traffic
selectors currently used.
- When responder narrows traffic selectors down when rekeying Child
SA, the narrowed traffic selectors SHOULD be either superset of
the traffic selectors used in the Child SA, or same as the traffic
selectors currently used.
- As rekeyed SA can never have narrower scope than currently in use,
there is no need for selectors from the packet (section 2.9), so
those selectors SHOULD NOT be sent.
If the rekeyed SA would ever have narrower scope than currently used
SA, that would mean that the policy was changed so that the currently
used SAs is against the policy, which means it should have been
already deleted after the policy change took effect.
----------------------------------------------------------------------
(Yes, I know, I changed my mind during the process :-)
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
