Paul Wouters writes: > > There is no other mimimal implementations that IKEv2 here, so I do not > > think we need to explictly mention it. Also the oritinal text > > explained that we need to send exactly one IKE_SA_INIT and one > > IKE_AUTH, which your text omits. Changed the text say: > > > > Minimal implementation only need to support the role of > > initiator, so it does not ever need to send any other request as > > one IKE_SA_INIT, and one IKE_AUTH message. > > I removed the counter of "1" because there could be retransmits and then > it sends more than one. How about: Hmm.. I would have considered retransmissions of IKE_SA_INIT, still being the one IKE_SA_INIT packet, ... > Minimal implementations only need to support the role of > initiator, so it typically only sends an IKE_SA_INIT request > which, when answered, is followed by an IKE_AUTH. But this text is ok for me too, so changed to this. > >> Incoming IKEv2 packets are mapped to an IKE SA only using the > >> packet's SPI, not using (for example) the source IP address of the > >> packet. > >> > >> As minimal implementation usually has only one host where it > >> connects, > >> > >> I'm not sure if this remark has any value - especially since the latter > >> sentence states it will only support one concurrent IKE and IPsec SA. > >> There isn't even "mapping" happening. > > > > Yes, but full IKEv2 implementations do use mappings, and this is also > > something that some implementors might need to change, i.e. instead of > > supporting exactly one host, it can have several. Thats why the text > > said "minimal implementations USUALLY has only one host". > > but minimal or not, one always uses the SPI as the lookup key for IKE > SAs and IPsec SAs. That's why I don't really understand why this remark > appears at all. But it isn't harmful, so I'm not against it. It is there to explain to new users who do not know anything about the IKEv2, that you do not use source IP to identify the IKE SA, you use SPI. > > Changed to: > > > > In the IKE_AUTH request, the initiator sends SA offer(s) in > > the SAi2 payload, and the proposed Traffic Selectors for the > > Child SA in the TSi and TSr payloads. The responder replies with > > the accepted offer in an SAr2 payload, and with the selected > > Traffic Selectors. > > Just change the first line to: > > In the IKE_AUTH request, the initiator sends the SA offer(s) in Fixed. > >> Minimal implementations do not support CREATE_CHILD_SA requests and MUST > >> reply to those with a CREATE_CHILD_SA reply containing the NO_ADDITIONAL_SAS > >> error notify payload. > > We could find a middle ground using "Minimal implementations that > do not support CREATE_CHILD_SA requests MUST ...." I do not want to add such MUSTs which changes the RFC7296. > The point of the paragraph is to make clear that if you don't support > it, you should not return like INFORMATIONAL, you should still return > CREATE_CHILD_SA but with some specific payload. So implementors need > to write a CREATE_CHILD_SA stub. If they fully implement it, we don't > need to say anything. The first sentence says that minimal implementation MUST be able to reply to incoming CREATE_CHILD_SA reqeusts. This means you need to send CREATE_CHILD_SA response back. The next question is, what is in the response you send back. It could be normal CREATE_CHILD_SA payloads, it could be error notify (either NO_ADDITIONAL_SAS, but someone might use some other error code also). > > We cannot add "MUST" here, as that would be against rfc7296. > > I don't see that. 7296 states: > > An implementation MAY refuse all CREATE_CHILD_SA requests within an IKE SA > > and: > > The responder sends a NO_ADDITIONAL_SAS notification to indicate that > a CREATE_CHILD_SA request is unacceptable because the responder is > unwilling to accept any more Child SAs on this IKE SA. This > notification can also be used to reject IKE SA rekey. Some minimal > implementations may only accept a single Child SA setup in the > context of an initial IKE exchange and reject any subsequent attempts > to add more. > > So I think it is clear from 7296 that if you do not implement > CREATE_CHILD_SA, that you must implement a stub CREATE_CHILD_SA > that still returns a valid CREATE_CHILD_SA exchange but only with > an error notification payload. You cannot respond with another > exchange, and you cannot respond with a fake CREATE_CHILD_SA that > for instance is not encrypted. Yes, but if we make text here say that MUST send NO_ADDITIONAL_SAS, then any implemenation following this document, is not allowed to fully support CREATE_CHILD_SA. Your original text said that if this document is supported, you do not support CREATE_CHILD_SA and you MUST reply with NO_ADDITIONAL_SAS. I do not agree on that statement. I think you can still be following this document and implement CREATE_CHILD_SA. > So to recap, why don't we: > > Minimal implementations that do not support CREATE_CHILD_SA requests MUST [...] > > > IKEv2 do > > allow you to implement CREATE_CHILD_SA, and minimal implementations > > are IKEv2 implementations, thus they can implement it. > > In this definition, a full ikev2 implementation is a minimal > implementation too :P The point of the document is to describe the > situation where it deviates :P We are trying to tell what features of IKEv2 MAY be left out, we do not specify what MUST be left out. > > I.e. minimal implementations MUST respond to the CREATE_CHILD_SA > > request with CREATE_CHILD_SA response, but that response can contain > > anything that is allowed by IKEv2, including error notification of > > NO_ADDITIONAL_SAS, but also it can support CREATE_CHILD_SA and reply > > with normal CREATE_CHILD_SA response. > > Yes, but that's out of scope of minimal clients. You whacked me about > minimal clients "single byte" importance, and then sneak in the entire > CREATE_CHILD_SA and multiple SA's :P What the minimal implemenations look like depends a lot from the actual usage. I do not think they will be implementing CREATE_CHILD_SA as it adds quite a lot of more code, for example after that you do need to keep track of incoming and outgoing message IDs. But on the other hand I do not want to add any normative text to say that some features MUST NOT be implemented. 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... -- kivinen@xxxxxx