On Tue, Jul 08, 2025 at 11:13:33AM +0300, Valery Smyslov wrote: > 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.
The messages I am referring are Cloudflare 5xx error messages. Which is more descriptive than http error codes. For e.g. here is one I found via google. https://i.sstatic.net/EhGbL.png And this one focus on 521. https://www.cloudpanel.io/tutorial/error-code-521/ These messages have useful info. Such as which instance you hit, how far it works. Note the Ray ID and timestamp. I imagine these can be used to open support cases with Cloudflare. > > 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. I understand IKE is not text-based. However, isn't it time to evolve? We need to exchange message that is more than normative error code list! Once the peer authenticated I see no reason to stick to minimal normative list. > > 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? logs are accessible. > > 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. See the CloudFlare example above. Their proxy can gather state information and send it over the https. I am envisioning IKE peer that decided to delete a connection has more info. This details along with some timestamp and transaction id can be send to the remote peer. Most case there is no need for manually entering these. > > (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.) I am not proposing delete info is a must. that is should not be reason to stop have something more modern:) > > 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? > > I was pointed out strongSwan already support for language preference exchanging. It implements RFC5793 sending language preference and response. May be this is one way to go for IKE? However, My instinct is to start with English only:) _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
