Dan McDonald described a worse case scenario.
It had the advantage that communication that could continue did
continue. It had the disadvantage that the traffic to port 2112
got delayed because we needed the packet contents to get the policy
right. This is bad due to the delay.
It required specifically:
- 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.
that the responder change it's policy slightly. As long as the
responder does not change it's policy again, I think that subsequent
rekeys may be fine.
It's nice that the responder can change its policy to a policy that
might in fact be a bit contradictory, yet communication continues.
(If the initiator sent packets through the old SA that the responder's
new policy does not allow, it may be able to drop those packets as being
from the wrong SA, so the responder does not need to be overly paranoid
and drop all SAs when it's policy changes. Whether this happens in
practice depends a bit upon how the details of tunnel exit checks are done)
{ps: I am using gmane.org to read the list via NNTP. These last three
emails elicited a request to confirm from core3.amsl.com, which I think
all the gmane.org people saw. I confirmed, but my emails did not show
up, so I am resending via SMTP instead of NNTP Post. My appologies if
this breaks the threading.}
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
