At IETF-118 I presented the issue on reason of deletion.
From the Introduction:
The IKEv2 [RFC7296] protocol supports sending a Delete Notify
message, but this message cannot convey the reason why a
particular Child SA or IKE SA is being deleted. It can be useful
to know why a certain IPsec IKE SA or Child SA was deleted by the
peer. Sometimes, when the peer's operator notices a specific SA
is down, they have no idea whether this is permanent or temporary
problem, and have no idea how long an outage might last. The
DELETE_REASON Notify message can be added to any exchange that
contains a Delete (42) payload specifying an estimated duration
and reason. Example reasons are specified in Section 5.
The payload defined had a TEXT field that could be used. There was some
discussion about the advantage and disadvantage of those with opinions
of:
1) enums are clearly specified and good to interop. And less bytes on the wire.
2) enums can't cover everything.
3) Why not both?
We can specify text, basically making those enum-like. But then it seems
we would still need some kind of registry. If we allow both, we could
do an enum registry (eg two octets) followed by text. Although I also
fear that if the free flow text is really needed on top of the enum,
then the enum system wouldn't really work and we end up using text as
defacto enum. So I'm more leaning towards a registy (simple, open First
Come First Serve for most entries, maybe reserve the first 1024 for
Standards Action).
The draft is here:
https://datatracker.ietf.org/doc/html/draft-pwouters-ipsecme-delete-info
Thoughs? Comments? (dis)agreements ?
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
