[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