Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption
RFC 5723

Note: This ballot was opened for revision 09 and is now closed.

(Jari Arkko) (was Discuss) Yes

(Pasi Eronen) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

Comment (2009-10-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Well-written and understandable doc.  I have one small editorial comment:

From section 5:

   Note 1:  The authenticated peer identity used for policy lookups may
            not be the same as the IDi payload (see Sec. 3.5 of
            [RFC4718]), and if so, MUST be included in the ticket.  Note
            that the client may not have access to this value.

What is the condition to be checked by "if so" and what is to be included based on that condition?  It would be clearer to include text that explicitly describes the condition and what is to be included.

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2009-10-07 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
INTRODUCTION, paragraph 13:
> Abstract

  Is long, and overlaps with the introduction a lot.

(Adrian Farrel) No Objection

Comment (2009-10-08 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I'm assuming that the malicious corrpution or deletion of stored tickets has only a small disruptive affect on session recovery. That is, an attempt will be made to recover the ticket before dropping abck to the current processing rules (pre-this-draft).
---
The use of ! rather than | in protocol object figures is unusual, but not illegal.
---
Section 7 identifies the different notification messages by "notification numbers" but the subsequent subsections (7.1 etc.) use the term "Notify Message Type". According to the IANA section and the registry, the latter term is correct.

(Russ Housley) No Objection

(Cullen Jennings) No Objection

Alexey Melnikov No Objection

Comment (2009-10-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
This is a useful document.
Some minor comments/questions below:

4.3.1.  Prologue

   Tickets are intended for one-time use, i.e. a client MUST NOT reuse a
   ticket.  A reused ticket SHOULD be rejected by a gateway.  Note that
   a ticket is considered as used only when an IKE SA has been
   established successfully with it.

Isn't this a recipe for DoS attacks?


7.1.  TICKET_LT_OPAQUE Notify Payload

   The data for the TICKET_LT_OPAQUE Notify payload consists of the
   Notify message header, a Lifetime field and the ticket itself.  The
   four octet Lifetime field contains a relative time value, the number
   of seconds until the ticket expires (encoded as an unsigned integer).

I suggest saying that the Lifetime is encoded in network byte order.

(Tim Polk) (was No Record, Discuss) No Objection

(Dan Romascanu) No Objection

Comment (2009-10-08 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Michael Sneed notes in his OPS-DIR review the following: 

Section 9.1 of the "Security Considerations"  could use some clarification: the inability of an attacker to use a stolen unencrypted "ticket by reference" is explained as "for the same reasons as for a ticket by value", but for a "ticket by value" the explanation is that the ticket is encrypted.

(Robert Sparks) No Objection