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(_at_)iki(_dot_)fi