[Swan-dev] IKEv1: Remove all IPsec SA's of a connection when newest SA is removedrefs/heads/master
D. Hugh Redelmeier
hugh at mimosa.com
Tue Aug 25 20:17:06 EEST 2015
| From: Paul Wouters <paul at nohats.ca>
| On Tue, 25 Aug 2015, D. Hugh Redelmeier wrote:
| > Why should deleting one SA delete another?
|
| Because the current SA being deleted _already_ replaced the older SA
| that we just kept lingering for a bit?
I don't think so. The way you described the original problem, two
identical tunnels are created through a race condition. So they both
will have similar lifetimes.
"replaced" is not a concept in IKEv1. It is a weak notion in our code.
There is no way to know if the other side shares that notion.
Off the top of my head, without due diligence, I would say that if one SA
is deleted, and it is the eroute owner, and there is an identical SA, it
should be made the eroute owner.
| We are not talking about a second
| tunnel here (from what I understand)
I think that we are. But the tunnels have essentially identical
policies.
| > Will deleting the SA generate a delete notification from us? (Deleting
| > without notification seems like a bad idea.)
|
| I think we already sent a delete for it? We are sending a regular delete
| for the one we are deleting just now.
I don't understand what you are saying here. In the changed code, are
we silently deleting the second tunnel when the first one is being
deleted, or are we sending a delete for the second one?
| > Is there any support in the RFCs for any of this?
|
| I'm not sure.
IMHO Delete Notification is an afterthought in the IKEv1 protocol and
not at all well-engineered or specified. And that is true of our code
for it too: it feels like we've had to revisit it too many times.
I think that moving the eroute is the cleanest answer to the original
problem. But that isn't a settled opinion.
More information about the Swan-dev
mailing list