<not wearing any hats>
1) First, sending a comment I already sent to the mailing list on
March 17:
In TLS session resumption, resumption basically creates a new TLS
"connection" (using information from local session cache, or ticket in
case of RFC5077), and does *not* really resume the old connection.
The old connection can still exist (and the session resumption
handshake won't cause it to be closed), or it could have been
interrupted earlier, or it could have been cleanly closed earlier.
The current ikev2-resumption draft, on the other hand, seems to assume
a quite different model, where resumption replaces the old connection,
and can be done only if the old connection was interrupted.
This would seem to preclude one case discussed earlier: I close my
laptop (cleanly) at work, commute, and reconnect at home (without
having to do EAP again; e.g. type in one-time password). Or "switch
off my phone (cleanly), fly to IETF meeting, and switch it back on".
In case of IKEv2, having multiple parallel IKE connections is probably
less common than with TLS (where it's very common), but to me it seems
using the IKE_SESSION_RESUME handshake when the old IKE_SA was cleanly
closed would be quite useful, and should be supported. (And making the
"new connection" completely independent of the old one might simplify
the protocol anyway.)
(Or in other words: I'd propose changing Section 7.2, 1st paragraph,
and making these MUSTs MAYs.)
2) The draft is currently very vague about the use cases for this
mechanism. As the discussion has shown, there's more than one use
case, and folks clearly have different opinions about which of them
are important and which are not.
However, being vague makes the draft quite difficult to understand for
a reader that hasn't participated in the discussions. I think the
draft should mention that there are several different use cases, and
give concrete examples (but not take an opinion about which of them
are important or not). Perhaps something like this (going somewhere in
Section 1):
Possible situations where the mechanism specified in this document
could be useful include the following (note that this list is not
meant to be exhaustive, and any particular deployment may not care
about all of these):
- If a client temporarily loses network connectivity (and the IKE
SA times out), this mechanism could be used to re-establish the
SA with less overhead (network, CPU, authentication infrastructure)
and without requiring user interaction for authentication.
- If the connectivity problems affect a large number of clients
(e.g., a large remote access VPN gateway), when the connectivity
is restored, all the clients might reconnect almost simultaneously.
This mechanism could be used to reduce the load spike for
cryptographic operations and authentication infrastructure.
- Losing connectivity can also be predictable and planned; for
example, putting a laptop to "stand-by" mode before travelling.
This mechanisms could be used to re-establish the SA when
the laptop is switch backed on (again, with less overhead and
without requiring user interaction for authentication).
3) Section 1, 2nd paragraph should also mention one additional reason
someone might have for using this mechanism (even if roundtrips or CPU
time is not an issue): doing the authentication from scratch could
require user interaction.
4) Some aspects of the protocol are described very thinly. For example:
- Section 4.2 describes what message is sent by the gateway, but not
what the client should do when it receives it
- Section 4.3 just says the gateway "accepts the ticket", but not
all the steps involved in this (there's lot about this in Sections 5
and 6 though)
- Section 4.3 says the client initiates an IKE_AUTH exchange, but
doesn't say much about how this differs from an ordinary IKE_AUTH
exchange (except for AUTH payload)
- Section 4.4 it's possible to use N(COOKIE) in IKE_SESSION_RESUME,
but nothing else (e.g. in IKE_SA_INIT request, N(COOKIE) must
always be the first payload -- but the message diagram earlier
puts other notifications at the end. Which is it?)
For all of these, I'm sure the authors have some idea how this is
supposed to work -- but I don't think the current text is very likely
to lead to interoperable implementations. I'd recommend taking
Sections 4.1...4.6, 4.8, 5 and 6 and doing a reorganization for that
text (Section 4.7 could probably be separate).
5) Section 5 and 6 present roughly the same information, and need to
be combined. Currently, the table I sent was just added to the end of
the old text (and some of the old text was plain wrong -- for example,
the client cannot obviously take the SA value from the ticket).
6) Section 6: The word "Unspecified" is probably wrong here -- this
document has to specify these (but clearly an implementation doesn't
have to include in the ticket any data it never uses).
7) Section 9.6, "using channel security" sounds like it would
refer to the IKEv2 encrypted payloads -- but that would be clearly
wrong?
8) The text about handling IDr is very unclear -- certainly the
gateway can't start to use some other IDr in the new IKE_SA,
without authenticating it?
9) Section 7.1: Why are storing SPIi/SPIr and the authentication
method "MUST"s? (The gateway doesn't seem to really need those
for anything)
Best regards,
Pasi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
