On Thu, 24 Sep 2015, Tero Kivinen wrote:
Thanks for the changes Tero. two topics left we haven't agreed on yet.
Minimal implementation need only support of being initiator, so it
does not ever need to send any other request as one IKE_SA_INIT, and
one IKE_AUTH message.
Minimal IKEv2 implementations only need to support the role of initiator
and only ever need to send out IKE Request messages for the IKE_SA_INIT
and IKE_AUTH exchange.
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:
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.
(if you reject this text, at least fix yours to use plural, eg minimal
implementations")
But it was added to the wrong paragraph where it does not belong.
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.
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
Here you suddenly waiver and add breathing room for various kind of
minimal implementations. But you have already defined it as not
supporting CREATE_CHILD_SA, so you should stick to that here:
There has been text earlier too which explaines that usually minimal
implementations do this and that.
Which i also did not like. You are trying to both define and not define
a minimal implementation.
Minimal implementations can support
whathever things they want to depending on the usage scenario where
they are used.
Sure, but you don't have to specify each variant between minimal and
full implementation. So you need to only say what the behaviour is of
the minimal client, and not extend it to describe behaviour of the
minimal implementation that also supports CREATE_CHILD_SA. We know what
clients do that support CREATE_CHILD_SA from RFC 7296. That's why my
suggested text tried to clarify the difference between not supporting
and exchange and supporting it well enough to say "not supported".
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 ...."
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.
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.
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
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
Paul