On Tue, May 05, 2009 at 04:01:19PM +0300, Tero Kivinen wrote:
<SNIP!>
> I do not really have strong opinion which way to go, but we either
> needs to make sure there is the triggering packet traffic selectors
> (which might be problematic if SA was rekeyed because of time) and the
> rekey can narrow down traffic selectors. Or we assume that narrowing
> case cannot happen, as the SAs were already deleted before they were
> rekeyed in such situations, and we can say that traffic selectors MUST
> NOT narrow down.
Let's assume the worst-case behavior and see what happens:
- An SA requires renewal due to time (e.g. a PF_KEY *SOFT lifetime*
expiration), and it does not contain original-triggering-packet
information. So an initiator just sends the selectors. Let's say
it's some sort of remote-port-only protection:
TSi = 0.0.0.0-255.255.255.255, proto any, port any
TSr = 0.0.0.0-255.255.255.255, proto TCP, port 2112
- If the existing SA selector set matches or is a subset of the
peer's SPD TS set, life is good.
- If the responder now has a more narrow set than the expiring SA's
selectors, (say some remote-peer's traffic for port 2112 is now
treated differently) the responder can send TS_UNACCEPTABLE to an
overly broad set of TSes.
- The rekey then fails, and then the initiator's SA actually
disappears due to time (e.g. a PF_KEY *HARD lifetime* expiration).
The initiator tries again with no SA available, and it is treated
like a brand-new negotiation (where triggering packet information
is more readily available).
If we go with "assume that the narrowing case cannot happen", even the above
worst-case behavior will continue to work, so long as the responder does the
right thing and rejects rekeying if the proposed traffic selectors are too
broad for its policy.
I would lean toward "assume that the narrowing case cannot happen", because
if the narrowing case DOES happen, then even if SAs are still lying around,
they can expire and negotiations can begin from scratch. It is much harder
to include the triggering packet's data all of the time, because if an SA
shared by many potential triggering packets, a time-expired renegotiation
CANNOT happen.
Dan
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
