I've now done my AD review for draft-ietf-ipsecme-ikev2-resumption-06.
Most of my comments are about clarifying text (so that readers who
didn't participate in the WG discussions can understand this
unambiguously), plus couple of nits.
Yaron and Hannes, could you post a new version addressing these
comments before we start IETF Last Call?
- The document uses the terms "ticket by value" and "ticket by
reference", but never really explains what those mean. Perhaps 4th
paragraph of Section 1 could be rephrased something like this?
The client (IKEv2 initiator) stores the state about the previous
IKE SA locally. The gateway (IKEv2 responder) has two options for
maintaining the IKEv2 state about the previous IKE SA:
o In "ticket by reference" approach, the gateway stores the state
locally, and gives the client an opaque reference (e.g., an index
to the gateway's table) that the gateway can later use to find the
state. The client includes this opaque reference when it resumes
the session.
o In "ticket by value", the gateway stores its state in a ticket
(data structure) that is encrypted and integrity-protected by a
key known only to the gateway. The ticket is passed to the client
(who treats the ticket as an opaque string), and sent back to
the gateway when the session is resumed. The gateway can then
decrypt the ticket and recover the state.
Note that the client behaves identically in both cases, and in
general, does not know which approach the gateway is using. Since
the ticket (or reference) is only interpreted by the same party
that created it, this document does not specify the exact format
for it. However, Appendix A contains examples for both "ticket by
reference" and "ticket by value" formats.
- Section 4.3.2 talks about setting SPIi or SPIr "to a random value".
Probably this should be "to a new (unused) SPI value" or something,
since it's perfectly OK to use non-random SPIs (e.g. if you support
maximum five simultaneous IKE_SAs, the SPI could be just index 1..5
to your local table).
- Section 5, "compiled by Pasi Eronen" -- this kind of stuff belongs
in the "Acknoledgements" section, not in the main text (but my name is
already there).
- Section 5: Peer vendor IDs cannot be "implementation specific" -- if
the old gateway sent Vendor ID "FOO", the client has to unambiguously
know whether it's allowed to FOO vendor-specific payloads to the new
gateway or not. Probably this should be "Not resumed, Vendor ID
payloads are resent in new exchange if required".
- Section 8 is not very clear about what IANA is asked to do.
Suggested text:
"Section 7 defines several new IKEv2 notifications whose values
are to be allocated (have been allocated) from the "IKEv2 Notify
Message Types - Status Types" registry.
Section 4.3.2 defines a new IKEv2 exchange type,
IKE_SESSION_RESUME, whose value is to be allocate (has been
allocated) from the "IKEv2 Exchange Types" registry."
- Section A.1 should say that the notation used for the example ticket
formats is intended to be pseudo-code, and does not specify exact
octet-by-octet format. (And probably things like "reserved[3]" should
be removed, since they don't really belong in pseudo-code like this.)
Best regards,
Pasi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
