Re: [IPsec] Another round of IKEv2-bis issues

[Tero Kivinen <[e-mail]>]

David Wierbowski writes:
> What is wrong with using a valid child SA?  If you are claiming
> the child SA is not valid because it's IKE SA on host A no longer
> exists then I'll agree.

Yes. The Child SAs are tied up to the IKE SA and if IKE SA dies, all
Child SAs needs to be deleted also. 

> When host A lost the IKE SA because the
> security processor failed it should have cleaned up any SAs created
> by the IKE SA.

If the information that this Child SA belongs to that IKE SA was on
the same security processor which had IKE SA then it cannot, and if
this is the case, then the implementation is broken.

If the Child SA on separate security processor still knows how to tie
itself to the IKE SA, and can clean up the state, then the
implementation is correct.

The text there said that you should not create such implementation
where the Child SA does not get deleted when IKE SA is deleted.
Instead you needs to make sure that you can clean up all Child SAs
when the IKE SA disappears. 

> That does not mean all SAs created by the IKE SA need
> be on the same security processor.

True. The text does not require that. It does require that you can
maintain the connection between IKE SAs and Child SAs, and if you
cannot, because of the setup, then you need to use separate IKE SAs. 

> That's just your rule and how you
> decided to handle the situation.  You could have kept knowledge of
> this relationship outside of the security processor.  I see no reason
> to dictate how to handle this situation in the RFC.

The RFC does not dicate solution, it dictates, that you need to solve
the problem and make sure that the IKE SA and Child SA connection
stays intact regardless of failures. And if you cannot ensure that
then you need to use separate IKE SAs. 

> 
> >This means that host B will
> >never start DPD, as it is seeing valid packets from host A coming in,
> >thus it will never notice that other Child SAs and the IKE SA on the
> >other security processor are dead, and will happily send data to them
> >without trying to recover.
> 
> Well if host A did not properly cleanup up all child SAs I agree this
> could happen, but so what?  Everyone is happy.  Data is being
> exchanged as per the child SA.  If host A did kill the child SA then
> dead peer detection would kick in as desired.

Data is exchanged over one SA, but there might be others on other
security processors, and from the Host B point of view those work too
(as IKEv2 assumes that either all Child SAs and IKE SA fail, or all of
them work). So Host B will send traffic to those SAs too, and that
will cause black hole, as those SAs did get destroyed when the failure
happened.

> It's all a matter of bookkeeping.  If they can fail separately you just
> need to keep track of what needs to be cleaned up when a failure
> occurs.

If you keep that bookkeeping, then they do not fail separately, so
this text does not apply. 

> >I do not agree on that. In most cases this is implementation hint that
> >is not needed, as most environments do not have multiple independent
> >security processors, but on those environments where we have those, it
> >is important for correct behavior that implementors implement this
> >correctly. Those who are really working on implementations on systems
> >which have multiple independent security processors should understand
> >what is said in the current text. As those people who do work on such
> >implementaions is extremely small, I do not think there is need to
> >add lots of material explaining the situation (as I did here in this
> >email), but keeping the text in the specification is still needed.
> 
> I do not agree.  The rule is simple.  If an IKE fails cleanup all Child
> SAs created by it.  In the case of a security processor failure you are
> guaranteed to have that happen if you keep the child SA on the same
> security processor, but that does not means that is the only way to
> do that.  You have some distribution logic in place to begin with.  That
> logic can save enough state to perform the proper cleanup.  I see no
> reason to address how this cleanup occurs in this RFC.

I think we need to mandate that logic you explained there to the RFC.
The text there does that. It says that you need to keep Child SAs and
IKE SAs connected, and either all of them work, or none of them work
(or you might also get delete notifications for those which failed,
provided the IKE SA stays up).

What is not allowed that some of the Child SAs stay up, but the IKE SA
does not (i.e. no delete notifications). And this from the remote
point of view, i.e. if you maintain internal bookeeping and destroy
the Child SA when one security processor fails, that is fine, and from
the remote point of view all Child SAs and IKE SA got destroyed. 
-- 
[e-mail]