Subject: [IPsec] AD review comments for draft-ietf-ipsecme-ikev2-resumption

From: "[email-masked]" <[email-masked]>
Date: Fri, 14 Aug 2009 10:36:12 +0200

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

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 15 Aug 2009 12:52:32 +0300

Hi Pasi,

Thanks for the useful comments. I'm OK with all of them, except for the last
one:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, August 14, 2009 11:36
> To: [email-masked]
> Subject: [IPsec] AD review comments for draft-ietf-ipsecme-ikev2-
> resumption
> 
[snip]
> be removed, since they don't really belong in pseudo-code like this.)

This is an example only, but it can still be precise. It *does* specify an
octet-by-octet format, except you're free to implement something else, or
change whatever you feel like. In general, I think an implementer is better
off starting from a precise definition than from a vague pseudo-code
description.

So, I propose to change the section preamble to:

This document does not specify a mandatory-to-implement or a
mandatory-to-use ticket format. The formats described in the following
sub-sections are provided as useful examples, and implementers are free to
adopt them as-is on change them in any way necessary.

Thanks,
	Yaron

---

From: Stephen Kent <[email-masked]>
Date: Sat, 15 Aug 2009 15:33:12 -0400

At 12:52 PM +0300 8/15/09, Yaron Sheffer wrote:
>C

I though the agreement was that the ticket content, as well as 
format, was entirely up to the implementer. If so, the text above is 
misleading, as it suggests that the content is prescribed and only 
the format is up for grabs.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 15 Aug 2009 18:03:29 -0700

At 3:33 PM -0400 8/15/09, Stephen Kent wrote:
>I though the agreement was that the ticket content, as well as format, was entirely up to the implementer. If so, the text above is misleading, as it suggests that the content is prescribed and only the format is up for grabs.

I disagree that the text suggests that the content is prescribed, but agree that this is a good place to remind the reader that the content is also implementation-specific. Proposed change:

This document does not specify a particular ticket format nor even the suggested contents of a ticket: both are entirely up to the implementer. The formats described in the following ...

--Paul Hoffman, Director
--VPN Consortium

---

From: <[email-masked]>
Date: Mon, 17 Aug 2009 09:57:51 +0200

Yaron Sheffer wrote:

> > - 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.)
> >
> 
> This is an example only, but it can still be precise. It *does*
> specify an octet-by-octet format, except you're free to implement
> something else, or change whatever you feel like. In general, I
> think an implementer is better off starting from a precise
> definition than from a vague pseudo-code description.

The text never specifies how e.g. "opaque state_ref" would be encoded
(e.g. if it's variable length, there's probably some kind of length
field somewhere), so IMHO it does not specify octet-by-octet format
(two persons reading this would very likely end up with different
octets).

Best regards, 
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 17 Aug 2009 14:33:30 +0300

> payloads are resent in new exchange if required".

As we are resuming back to the same GW (failover from one GW to
another was specific non-goal for this document), I think we can
safely assume that GW support exactly same vendor IDs which it did
last time we connected it (or if the GW version was changed and
support for some vendor IDs were removed, then resumption tickets were
also invalidated).

So in this case the "implementation specific" is quite ok. I.e if
server and client support extension "FOO" indicated by vendor ID
"FOO", which requires some external data to be stored, then that
information that "FOO" was supported and that information was stored
to ticket needs to be stored to ticket.

If the extension "FOO" does not need any data to be stored across the
resumptions, then there is no need to modify ticket, thus there is not
really need to store information whether "FOO" was supported in the
first place or not.

Then there is this second case whether client is allowed to "remember"
that gateway supported extension "FOO" without sending any Vendor ID
payloads, or whether they need to be resent. I think we should require
them to be resent, as you said there.

But there is still cases where ticket might need to store extra
information depending whether vendor ID was originally used or not.

So I think we need two separate cases one for "Supported Vendor IDs"
which is "Not resumed, Vendor ID payloads are resent in new exchange
if required", and some kind of "Vendor ID specific data", which is
"Implementation specific (needed in ticket only, if vendor-specific
state is required)".

BTW, the table would be much more readable if there would be some kind
of separators between items, i.e. change to be:

   +------------------------------------+------------------------------+
   | State Item                         | After Resumption             |
   +------------------------------------+------------------------------+
   | IDi                                | From the ticket (but must    |
   |                                    | also be exchanged in         |
   |                                    | IKE_AUTH).  See also Note 1  |
   +------------------------------------+------------------------------+
   | IDr                                | From the ticket (but must    |
   |                                    | also be exchanged in         |
   |                                    | IKE_AUTH)                    |
   +------------------------------------+------------------------------+
   | Authentication method (PKI,        | From the ticket              |
   | pre-shared secret, EAP, PKI-less   |                              |
   | EAP                                |                              |
   | [I-D.eronen-ipsec-ikev2-eap-auth]  |                              |
   | etc.)                              |                              |
   +------------------------------------+------------------------------+
   | Certificates (when applicable)     | From the ticket, see Note 2  |
   +------------------------------------+------------------------------+
   | Local IP address/port, peer IP     | Selected by the client, see  |
   | address/port                       | Note 3                       |
   +------------------------------------+------------------------------+
   | NAT detection status               | From new exchange            |
   +------------------------------------+------------------------------+
   | SPIs                               | From new exchange, see Note  |
   |                                    | 4                            |
   +------------------------------------+------------------------------+
   | Which peer is the "original        | Determined by the initiator  |
   | initiator"?                        | of IKE_SESSION_RESUME        |
   +------------------------------------+------------------------------+
   | IKE SA sequence numbers (Message   | Reset to 0 in                |
   | ID)                                | IKE_SESSION_RESUME, and      |
   |                                    | subsequently incremented     |
   |                                    | normally                     |
   +------------------------------------+------------------------------+
   | IKE SA algorithms (SAr)            | From the ticket              |
   +------------------------------------+------------------------------+
   | IKE SA keys (SK_*)                 | The old SK_d is obtained     |
   |                                    | from the ticket and all keys |
   |                                    | are refreshed, see           |
   |                                    | Section 5.1                  |
   +------------------------------------+------------------------------+
   | IKE SA window size                 | Reset to 1                   |
   +------------------------------------+------------------------------+
   | Child SAs (ESP/AH)                 | Created in new exchange, see |
   |                                    | Note 7                       |
   +------------------------------------+------------------------------+
   | Internal IP address                | Not resumed, but see Note 5  |
   +------------------------------------+------------------------------+
   | Other Configuration Payload        | Not resumed                  |
   | information                        |                              |
   +------------------------------------+------------------------------+
   | Peer vendor IDs                    | Implementation specific      |
   |                                    | (needed in the ticket only   |
   |                                    | if vendor-specific state is  |
   |                                    | required)                    |
   +------------------------------------+------------------------------+
   | Peer supports MOBIKE [RFC4555]     | From new exchange            |
   +------------------------------------+------------------------------+
   | MOBIKE additional addresses        | Not resumed, should be       |
   |                                    | resent by client if          |
   |                                    | necessary                    |
   +------------------------------------+------------------------------+
   | Time until re-authentication       | From new exchange (but       |
   | [RFC4478]                          | ticket lifetime is bounded   |
   |                                    | by this duration)            |
   +------------------------------------+------------------------------+
   | Peer supports redirects            | From new exchange            |
   | [I-D.ietf-ipsecme-ikev2-redirect]  |                              |
   +------------------------------------+------------------------------+

Also it is bit funny that there is notes 6 and 8, which are not
referenced anywhere. As those are generic rules for processing data
not covered explictly here, it might be better to make them separate
paragraph after the table, instead of hiding such important
information to the non-referenced notes.

There is also missing closing parenthesis in the end of section 3,
i.e. change

      Moreover, this document requires the client to destroy the ticket
      when the user explicitly "logs out" (Section 6.2.

to

      Moreover, this document requires the client to destroy the ticket
      when the user explicitly "logs out" (Section 6.2).
-- 
[email-masked]

---

From: <[email-masked]>
Date: Mon, 17 Aug 2009 13:52:17 +0200

For most other features (e.g. whether peer supports MOBIKE or not),
the draft already says that the relevant payloads (e.g. MOBIKE_SUPPORTED)
are sent in the new exchange (instead of assuming everything has
remained the same).

IMHO the simplest alternative would be to use the same approach
for Vendor IDs, too. This is needed even when no vendor-specific
data is stored in the ticket, because vendor IDs define how
to interpret numbers from the "private use" range...

Best regards,
Pasi

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Tero Kivinen
> Sent: 17 August, 2009 14:34
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]
>    |                                    | IKE_AUTH)
> |
>    | EAP                                |
> |
>    | etc.)                              |
> |
>    | address/port                       | Note 3
> |
>    |                                    | 4
> |
>    |                                    | normally
> |
>    |                                    | are refreshed, see
> |
>    |                                    | Section 5.1
> |
>    |                                    | Note 7
> |
>    | information                        |
> |
>    |                                    | required)
> |
>    |                                    | resent by client if
> |
>    |                                    | necessary
> |
>    |                                    | by this duration)
> |
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec