Yoav Nir writes: > I don't think we should really prohibit such extensions and > enhancements. It's just that IKE will fail if you try it with a > peer that does not support it.
Yes, but most likely it will ignore unauthenticated error notifications too, so it will fail only after timeout. > As far as the end-user is concerned, this is not different from an > UNSUPPORTED_CRITICAL_PAYLOAD in IKE_AUTH. Either way, the tunnel > setup fails. Yes. > Do you see any cause for concern in the UNSUPPORTED_CRITICAL_PAYLOAD > being sent in a non-encrypted unauthenticated message? It can be sent, but as the UNSUPPORTED_CRITICAL_PAYLOAD contains the payload number in, it might be good idea to say that if the payload which had that critical payload was encrypted, then the notification must also be encrypted (this applies to the especially to IKE_AUTH). If such error happens during IKE_SA_INIT, then response will be in clear anyways, and it will most likely be ignored by the initiator anyways (it could use it to shorten its timeouts, but must not fail the negotiation immediately). Question really is, if we want to add something about this to the document or not? -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
