Paul Wouters writes:
We are trying to tell what features of IKEv2 MAY be left out, we do
not specify what MUST be left out.
Yes, but I was trying to address the confusion of what it means if
something is "left out". If support for create_child_sa is left out,
does that mean you need to reply to such a request with that exchange
number, or use an informational exchange type. That is the confusion
I see developers could have. To me it seems even if you do not want
to support CREATE_CHILD_SA, you still need to implement answering a
CREATE_CHILD_SA with an error notify.
Yes.
And in the exchanges section there is text saying that:
In addition to those messages minimal IKEv2 implementation need
to understand the CREATE_CHILD_SA request enough to generate an
CREATE_CHILD_SA response containing the NO_ADDITIONAL_SAS error
notify.
And this is expanded in the Other Exchanges section with text:
Minimal implementations MUST be able to reply to incoming
CREATE_CHILD_SA requests. Typical implementation will reject the
CREATE_CHILD_SA exchanges by sending NO_ADDITIONAL_SAS error
notify back:
I think tihs is clear enough.
For example the other implementation we had did implement NAT-T,
mostly because he wanted to get the ESP packets inside the UDP
encapsulated packets over port 4500, and not mess up with privileged
port 500, and raw sockets. If the text would say NAT-T MUST NOT be
implemented, his implemented would not be following this spec...
I was only trying to say that IF you do not support CREATE_CHILD_SA,
then you MUST still support enough of it to answer with a
CREATE_CHILD_SA stating an error code. That is different from say,
not supporting SESSION_RESUMPTION or Exchange Number 666.
I think the two sections I quoted above, do say that quite clearly.
Anyway, for the record. With the changes of me that you applied, I am
fine with the document moving forward. Thanks for your work on this.
Ok, posting new version shortly which includes latest changes.
--
kivinen(_at_)iki(_dot_)fi