Yaron Sheffer writes: > > 1.4.1: the last paragraph springs a surprise by defining the behavior > > of IKE SA deletion while discussing an unlikely "messing up" of Child > > SAs. IKE SA deletion deserves its own subsection. > > > > [[ Response: it is optional behavior and makes sense. If you want a > > section on IKE SA deletion, you have to write it. I propose that it > > might be very late for doing that. ]] > > > I suggest replacing the last paragraph by the following text (not a > new section, though): > > Similarly to ESP and HA SAs, IKE SAs are also deleted by sending an > Informational exchange. Deleting an IKE SA implicitly closes any > remaining Child SAs negotiated under it. The response to a request > that deletes the IKE SA is an empty INFORMATIONAL response. > > Half-closed ESP or AH connections are anomalous, and a node with > auditing capability should probably audit their existence if they > persist. Note that this specification nowhere specifies time > periods, so it is up to individual endpoints to decide how long to > wait. A node MAY refuse to accept incoming data on half-closed > connections but MUST NOT unilaterally close them and reuse the SPIs. > If connection state becomes sufficiently messed up, a node MAY close > the IKE SA, as described above. It can then rebuild the SAs it needs > on a clean base under a new IKE SA.
I support doing that change, as it does clarify things. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
