Paul Wouters writes:
> > The use case is to wake up, create IKE and IPsec SA, send few packets,
> > go back to sleep. In most cases the send few packets, is really send
> > few packets, and got some kind of ack back, so if there is no ack, the
> > client can try again little bit later (i.e. instead of going to sleep
> > for an hour, only sleep for minute, and then try again).
>
> Okay, understood. Although perhaps then you can clarify this by saying
> the use case is "to wake up, create IKE and IPsec SA, send few packets,
> delete all state and go back to sleep".
I currently have following text:
While the device is sleeping it will not maintain the IKEv2 SA,
i.e., it will always create the IKEv2 SA again when it wakes up.
I think that should be enough?
> Some remarks about specific text:
>
> In these calculations, IDi' and IDr' are the entire ID payloads
> excluding the fixed header and the Ni, and Nr are only the value, not
> the payload containing it.
>
> This paragraph defines IDi' but that definition is already used above
> it. Can we move this paragraph to above the first use of IDi'
Done, and changed the paragraph to say "In following calculations,
..." and moved it before the "The initiator signs ..." paragraph.
> GenIKEHDR = [ four octets 0 if using port 4500 ]
>
> since NAT-T is not supported, this never happens. Should it be left out
> of the description? Same for the next occurance.
Yes. Removed.
> Note, that INFORMATIONAL and CREATE_CHILD_SA requests might contain
> unsupported critical payloads, in which case complient implementation
> MUST ignore the request, and send response message back having the
> UNSUPPORTED_CRITICAL_PAYLOAD notification.
>
> That's a little weird, as most core IKEv2 payloads from the base RFC
> 7296 are assumed critical (I thought even without a critical flag) .
> And if these clients do not support them, they do not know that these
> are critical payloads?
Minimal clients will understand all payloads in the base IKEv2, in
such extend that it knows it can ignore them. I.e. if it receives
Delet, Notify or Certificate Payloads, it will simply ignore them.
This is how it is specified in the RFC7296. So because of that it does
not need to say it does not support them.
In most cases there is no need to put the critical payload on any of
the newly defined payloads. Most of the time when new extensions to
IKEv2 is done the first draft version says those new payloads are
marked as critical, but then the bit is removed after the draft
authors understand what critical bit means.
We do not currently have any extensions using critical payloads, so I
think we do not really need to care about them that much. I do not
also expect there to be critical payloads in future, as in most cases
we negotiate feature beforehand and after we have agreed that both
ends support feature X, we do not need to mark those payloads related
to feature X with critical flag, as we do know both ends support them.
Only time we would really need critical flag is when we would do
extension that would affect IKE_SA_INIT. Even it that case it might be
better to use new exchange like we did in session resumption.
> I am undecided on what is better, UNSUPPORTED_CRITICAL_PAYLOAD or
> NO_ADDITIONAL_SAS.
Unsupported critical payload cannot be used, as we do not have any
payloads we could point that we do not understand. All the payloads in
CREATE_CHILD_SA are already something the minimal client will
understand, and they are not marked as critical, so we cannot send
UNSUPPORTED_CRITICAL_PAYLOAD back.
> The remainder are grammar/spelling nits:
>
>
> The minimal implementation of IKEv2 only uses first two exchanges
>
> first -> the first
Fixed.
> called IKE_SA_INIT and IKE_AUTH. Those are used to create the IKE SA
>
> those -> these
Fixed.
> and the first child SA. In addition to those messages minimal IKEv2
> implementation need to understand CREATE_CHILD_SA request so it can
> reply with CREATE_CHILD_SA error response saying NO_ADDITIONAL_SAS to
> it, and understand INFORMATIONAL request so much, it can reply with
> empty INFORMATIONAL response to it.
>
> In addition to those messages minimal IKEv2 implementations need to
> understand the CREATE_CHILD_SA request enough to generate an
> CREATE_CHILD_SA IKE Response message containing the NO_ADDITIONAL_SAS error notify.
> It needs to understand the INFORMATIONAL IKE Request message enough to generate
> an empty INFORMATIONAL IKE Response message.
Section "2. Exchanges" already defines request and response as being
messages, there is no point of saying "request message" / "response
message". Also there is no need to talk about "CREATE_CHILD_SA IKE" or
"INFORMATIONAL IKE" request/response messages. The "CREATE_CHILD_SA
request" should be clear enough.
Rewrote the section to say:
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. It needs to understand the INFORMATIONAL request enough
to generate an empty INFORMATIONAL response to it.
> 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.
> As those messages have fixed Message IDs (0
> and 1) it does not need to keep track of its own Message IDs for
> outgoing requests after that.
>
> As the IKE_SA_INIT and IKE_AUTH exchange messages have a fixed Message
> ID (0 and 1 respectively), Minimal IKEv2 implementations do not need to
> keep track of their own Message IDs. For IKE Response Message IDs, the
> Message ID of the received IKE Request is used.
The last text abou tresponse messages is talked in the next paragraph,
and does not belong here, and I think my text about the message ids
for outgoing requests is clearer.
> or empty notifications replies
>
> or empty notification replies
Fixed.
> can always answer to request coming in, with the same Message ID than
> what the request had
>
> See my above added sentence that replaces this one.
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".
>
> In the IKE_AUTH initiator sends SA offer(s) in the SAi2 payload, and
> the proposed Traffic Selectors for the proposed Child SA in the TSi
> and TSr payloads. The responder replies with the accepted offer in
> an SAr2 payload, and selected Traffic Selectors.
>
> In the IKE_AUTH Request message, the initiator sends the 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.
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.
> In the wildcard case the server quite often narrow the range down
>
> narrow -> narrows
Fixed.
> Using
> single IP address pair as a traffic selectors when sending IKE_AUTH
> will simplify processing as then server will either accept that pair
> or return error.
>
> Using a sigle IP address pair as the Traffic Selectors when sending the
> IKE_AUTH Request will simplify processing as the responder will either
> accept the IP address pair or return an error.
Changed to:
Using a single IP address pair as the Traffic Selectors when
sending the IKE_AUTH request will simplify processing as the
responder will either accept the IP address pair or return an
error.
> If wildcard ranges are used, there is possibility
> that server narrows the range to some other range than what was
> intended.
>
> If wildcard ranges are used, there is a possibility that the responder
> will narrow the Traffic Selector range to range that is not acceptable
> by the initiator.
Changed.
> which can be ignored by minimal implementation.
>
> "by a minimal implementation" or "by minimal implementations"
I think the "by minimal implementations" is better. Changed to that.
> but any payload unknown to minimal implementation
>
> "minimal implementation" or "minimal implementations"
Changed to "minimal implementations".
> notification payloads which can be ignored by minimal implementation.
>
> "a minimal implementation" or "minimal implementations"
I assume this is same as the one above.
> that is quite commonly sent by the minimal implementation.
>
> by a minimal implementation.
Fixed.
> that the initiator does not have any other IKE SAs between them
>
> that the initiator does not have any other IKE SAs between it and
> the responder.
Changed.
> they can be deleted.
>
> those can be deleted by the responder.
Changed.
> As minimal implementation does not delete
> IKE SAs by sending IKE SA delete, this will help server to clean up
> leftover state.
>
> As minimal implementations delete IKE SAs without sending IKE SA delete
> requests, this will help the server to clean up leftover state.
Changed.
> Responder might also reply with IKE_AUTH response packet which do not
> contain payloads needed to set up Child SA (SAr2, TSi and TSr), but
> contains AUTH payload and an error. As minimal implementation
> probably do not support multiple SAs nor sending the CREATE_CHILD_SA
> exchanges the IKE SA is useless for initiator.
>
> The responder might also reply with an IKE_AUTH response packet which
> does not contain the payloads needed to set up a Child SA (SAr2, TSi and
> TSr) and instead contain an AUTH payload and an error. Minimal
> implementations that do not support the CREATE_CHILD_SA exchange cannot
> recover from this scenario.
Changed.
> Minimal implementation MUST be
>
> Minimal implementations MUST be able to reply to INFORMATIONAL requests
> by sending back an empty INFORMATIONAL response.
Changed.
> Minimal implementation also MUST be able
>
> Minimal implementations MUST be able
Changed.
> Typical implementation will reject
>
> 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. Minimal implementations can support
whathever things they want to depending on the usage scenario where
they are used.
> 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 cannot add "MUST" here, as that would be against rfc7296. IKEv2 do
allow you to implement CREATE_CHILD_SA, and minimal implementations
are IKEv2 implementations, thus they can implement it.
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.
--
kivinen@xxxxxx