Hi Antony, > Hi Valery, > Thanks for your thoughts. > > I'd like to offer a different perspective—as someone who has spent a lot of > time debugging IKE in operational environments. In those situations, I’ve > often found IKE error codes difficult to interpret and diagnose. This draft > aims to improve that situation for delte message. Note in this case there > less chace abouse. The peer is already authenticated... > Simple registries alone are not sufficient. A short, optional free-text > diagnostic message—with strict length limits, of course—could have saved me > considerable time and effort, especially in cases where connections were > administratively blocked.
Then I have a question - where this text would come from? I doubt if there is a human being on the other side of connection who will enter this text in case of operational failure for you to see it. Most probably this text will be precompiled into the IKE implementation, so there will be limited number of well-known text strings, for every reason the implementation has to delete an SA. If you standardize these text strings in your draft, then I see no difference comparing to sending error codes. If not, then you may sometimes have a hard time trying to determine what this particular string really means (implementers are often creative in describing various reasons, an not all of them have good English). > I like how some Cloudflare messages include a transaction ID and a brief > explanatory message. That kind of diagnostic feedback can make a real > difference. On the other hand, HTTP only normatively defines error codes, and we all know what 404 means without any supplementary text. > I understand your concern about English being the default, but I don’t > believe that should prevent us from including diagnostic messages. Many > Internet protocols began with English and continue to use it effectively. > Leaving room for future multilingual support seems more constructive than > excluding the feature altogether. I think you are talking about text-based protocol (e.g., ftp). IKE is not a text-based protocol. > Regarding IKE being a low-level protocol—I agree, and that’s often a > strength and weakness. But that same low-level nature also makes it harder > to diagnose. As the protocol has grown in complexity, the need for better > diagnostics has only become more evident? I wonder how you do your diagnostics? I doubt that you manually parse binary structures of IKE messages. Most probably you use some logging capability of your implementation, which performs a human-friendly presentation of what was received from the peer. Then the question - why this logging engine cannot convert delete reason code sent by your peer to a string (and in the language you prefer)? Am I missing something? > Wearing my author hat: I’ve also heard strong support from others that > free-form text is sometimes the only practical way to communicate unexpected > or unregistered errors. Especially in secure environments, where logs may be > sparse or inaccessible, an optional text message can be invaluable. These text strings will be inside encrypted IKE messages, so you generally cannot see them by until IKE decrypt message and log its content. If logs are inaccessible, how are you going to see these strings? With regard to unregistered errors: who will be responsible for creating these strings? If you allow system administrator to provide these strings, then you may sometimes have hard time trying to understand them. (Each time I want to reboot a Windows Server, it requires me to enter a reason. I usually enter something like ";lsadyihKLJHNSC" to make it happy. I don't care if anybody reads this.) Regards, Valery. > I’m open to suggestions on how to make this safe and interoperable. In my > view, > concerns about English-only support shouldn’t be used to dismiss the idea > outright. The only reason the current draft uses English is due to author's > lack of expertise in internationalization. I’d welcome input from others who > can help define a more flexible or extensible approach. Would anyone like > share some pointer how to send messages in low lever protocol? > > At one point, I considered dropping the free-text message to help advance the > draft as a Standards Track document. To take path of least resistance. But > since this is currently positioned as experimental, I now feel there’s no > reason to compromise. Let’s run the experiment. If the outcome is that free > text turns out to be a bad idea, we’ll have the data to justify removing it > later when it goes to standard. > > best regards, > -antony > > On Mon, Jun 30, 2025 at 10:45:36AM +0300, Valery Smyslov wrote: > > Hi Paul, > > > > I prefer option 3) - without text fields regardless of the intended status > > :-) > > > > The argument is not "strings are hard", sometimes they are easier than > > reason > codes. > > The actual reasons why I think this idea is bad are: first, these strings > > are > intended to be read > > by humans and only in one language (English), which I think is not > > appropriate > for > > the Internet-wide protocol. And second - I think that IKE is a low-level > > enough > protocol > > to not deal with strings at all (e.g., you don't have strings in ICMP). > > > > Regards, > > Valery. > > > > > Hi, > > > > > > [ speaking wearing only by Authors hat ] > > > > > > The authors have a question on > > > https://datatracker.ietf.org/doc/html/draft- > > > pwouters-ipsecme-delete-info > > > > > > We had some discusison about the text field for "delete reason" in > > > draft-pwouters-ipsecme-delete-info. Some people liked it and some did > > > not. Mostly it was regarding fear of security and internationalization. > > > This resulted in -02 having the field and -03 having the field removed: > > > > > > https://author-tools.ietf.org/iddiff?url1=draft-pwouters-ipsecme-delete-info- > > > 02&url2=draft-pwouters-ipsecme-delete-info-03&difftype=--html > > > > > > However, the authors didn't agree with each other on which is best, > > > especially in the light of the document also moving from -02 as Standards > > > Track to -03 as Experimental. Since the reasons for removal of the text > > > field was "strings are hard, dont do it", one could argue that if we are > > > Experimental, why not try the strings and see how it works, then decide > > > later when/if it moves to Standards track on whether the text field was > > > a success or not. > > > > > > So the authors would like some input. Which do you prefer (and why): > > > > > > 1) Standards Track without text field > > > 2) Experimental Track with text field > > > 3) Other > > > > > > We hope to get some feedback this week so we can push a new draft before > > > the cut-off and maybe have some running code for IETF 123. > > > > > > Paul, on behave of all the authors :) > > > > > > _______________________________________________ > > > IPsec mailing list -- [email protected] > > > To unsubscribe send an email to [email protected] > > > > _______________________________________________ > > IPsec mailing list -- [email protected] > > To unsubscribe send an email to [email protected] _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
