On Wed, 23 Sep 2015, Tero Kivinen wrote:
Tero,
Thanks for the feedback. ExecSum: I think the document is fine. I have
some small comments left and a few spelling/grammer changes.
In the draft there is only requirement for replying with empty
INFORMATIONAL response to the requests. No support for INFORMATIONAL
requests is required.
Or did you mean "Support for sending an
empty INFORMATIONAL message" only as an IKE RESPONDER?
Where is that text? I cannot find it in the draft.
You are right. I got confused by the email text. So the delete issue
I raised is not a problem. Thanks for the clarification on that.
And while you changed your use case, you did not actually address the
problem I described above for those clients that do keep an IPsec SA
open. I still think it would be good to mention, and possibly recommend
that minimal IKE clients always setup a new IKE and IPsec SA to prevent
my problem scenario.
Such implementation would no longer be minimal, thus it would be
something bit more than minimal implementation, but not yet full
implementation. That is one of the reasons I do not want to have
notify specifying that client is minimal implementation, as the level
of minimalness will be different in different cases. Some implementors
will implement really the bare minimal. Some will also add support for
sending delete notifications. Some use Raw public keys etc.
I'm fine with that being a requirement of minimal ike. It would still be
useful to mention this issue, and recommend that if the minimal ike
client wakes up from sleep, that it always starts a fresh new IKE SA
negotiation.
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".
So short timeouts would make the situation worse - it
would be like the remote gateway crashed all the time without the
client being able to recover. The only short cut I can see here is
if the minimal IKE client treats all incoming informational messages
as fatal, and deletes the IKE SA with the IPsec SA. So perhaps say
that?
No, as that would make liveness checks from the server cause the
client to restart.
True. Okay forget about liveness and deletes. I take it back and agree
that this is out of scope for minimal clients.
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'
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.
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?
I am undecided on what is better, UNSUPPORTED_CRITICAL_PAYLOAD or
NO_ADDITIONAL_SAS.
The remainder are grammar/spelling nits:
The minimal implementation of IKEv2 only uses first two exchanges
first -> the first
called IKE_SA_INIT and IKE_AUTH. Those are used to create the IKE SA
those -> these
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.
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.
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.
or empty notifications replies
or empty notification replies
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.
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.
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.
In the wildcard case the server quite often narrow the range down
narrow -> narrows
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.
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.
which can be ignored by minimal implementation.
"by a minimal implementation" or "by minimal implementations"
but any payload unknown to minimal implementation
"minimal implementation" or "minimal implementations"
notification payloads which can be ignored by minimal implementation.
"a minimal implementation" or "minimal implementations"
that is quite commonly sent by the minimal implementation.
by a minimal implementation.
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.
they can be deleted.
those can be deleted by the responder.
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.
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.
Minimal implementation MUST be
Minimal implementations MUST be able to reply to INFORMATIONAL requests
by sending back an empty INFORMATIONAL response.
Minimal implementation also MUST be able
Minimal implementations MUST be able
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:
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.
Paul