Subject: [IPsec] Some comments to draft-ietf-ipsecme-ikev2-resumption-02.txt

From: Tero Kivinen <[email-masked]>
Date: Tue, 21 Apr 2009 15:47:31 +0300

During the other discussion I read the
draft-ietf-ipsecme-ikev2-resumption-02 through and here are some more
generic comments to it:

---

In Section 3 we present 2 use cases, and then after figure 1 start
talking about "In this scenario..." and I think that refers to first
use scenario described in second paragraph of section 3, not the
second use scenario described just above that in third paragraph. It
would be useful to change the "In this scenario..." to explicitly
mention which one of those two scenarios it is talking about. As far
as I can understand the second use scenario is not talked in detail
anywhere, i.e. only reference to it is 3rd paragraph of section 3.

---

In Section 4.3, it might be good idea to clarify that reuse of the
ticket is when you successfully use it, not just when you try to use
the ticket, i.e. client can try to send IKE_SESSION_RESUME exchanges
every now and then to the server and ticket is only really used when
it gets reply from server.

---

Also the text "The client SHOULD NOT use this exchange type unless it
knows that the gateway supports it." is bit pointless, as at least
from my understanding is that when server presents ticket to client it
indicates the gateway supports this, thus if client has ticket it can
use this exchange. If client does not have ticket it cannot use this
exchange anyways, as ticket is required for this exchange.

---

I would also like to rename TICKET_OPAQUE' to something else, perhaps
use TICKET_REQUEST, TICKET_REPLY, TICKET_PRESENT or similar names
instead (main reason for that is that I like to define those names to
actual defines in C-code or similar, and then I need to rename
TICKET_OPAQUE' to something like TICKET_OPAUQE_DOT or so).

---

Why is the IDr there? I know I asked this before, but I do not sill
understand why it is there. Gateway cannot have multiple identities
having different session resumption caches, as IDr is encrypted,
meaning gateway needs to parse presented ticket first, and that ticket
must have information of which identity the connection is connecting
so it can select suitable session resumption cache. Section 4.7 says
that IDr is obtained from the new exchange, so that seems to indicate
it is used, but IDi, and IDr is used to check PAD, which is then used
to check SPD entries etc, and I do not think we want to redo policy
lookups at this point.

Also in normal IKE we do not directly use the IDr that client sent, we
use that as hint when selecting one of the our own allowed IDr for
this connection. The text in 4.7 would indicate that we directly use
the IDr client sent us as is.

The IDi was already removed, but is there any reason to keep the IDr
there? Even if it is kept, the section 4.7 will most likely need text
saying that IDr is selected as normally, i.e. the IDr from exchange is
only used as hint. Also note that the gateway does not tell back to
the client which IDr it finally decided to use...

---

Also still in section 4.3 when talking about the response packet, the
text about what is filled in the SPI fields is wrong. For the response
packet the SPIi value is of course copied from the request, and SPIr
is filled with random number allocated by the responder (gateway).

---

Section 4.3 also needs to clarify what is going to be message IDs of
the exchanges. Especially with the 2 RT version there is two options,
i.e. it could be that the cookie exchange has message ID of 0, and
actual exchange has message ID of 1. When the cookie exchange was
optional, then it was quite clear that all of the IKE_SESSION_RESUME
exchange messages have message ID of 0.

---

In section 4.7 it says "The sequence numbers are reset to 0.". I was
trying to search that earlier, but didn't find it because I searched
using "Message ID" text... Unfortunately IKEv2 document uses both
"sequence number" and "Messsage ID". It uses "Message ID" bit more,
and good thing with "Message ID" term is that it cannot be confused
with the sequence numbers of the ESP/AH packets. I would recommend
changing that text to "The Message ID counters are reset to 0.".

---

Section 5.2 says that "The lifetime of the ticket carried in the
N(TICKET_OPAQUE) notification SHOULD be the minimum of the IKE SA
lifetime and its re-authentication time", and also that "The gateway
SHOULD set the expiration date for the ticket to a larger value than
the lifetime of the IKE SA."

That is bit confusing, and at first looks like it is conflicting. I
assume it was supposed to say that the lifetime sent in the ticket is
actually different that what is enforced by the server, i.e. server
should allow ticket also after the life time sent to client? Hmm.. on
the other hand client MUST NOT present ticket which is expired...
Actually I am not sure what the current text is trying to say. I.e. is
the ticket lifetime supposed to be same or smaller than IKE SA
lifetime, or larger?

(On the other hand I still think the whole lifetime concept should be
removed from this document, but lets not go there here :-)

---

It still does not say whether ticket is valid after IKE SA rekey. It
does say it is allowed to request new ticket when doing
CREATE_CHILD_SA exchange to rekey IKE SA, but it does not say whether
the old ticket is valid after rekey. 
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 21 Apr 2009 16:18:27 +0300

Hi Tero,

I have opened Issue #101 for your comments (being too lazy to process them
into multiple issues), and we will process them in batch mode.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tero Kivinen
> Sent: Tuesday, April 21, 2009 15:48
> To: [email-masked]
> Subject: [IPsec] Some comments to draft-ietf-ipsecme-ikev2-resumption-
> 02.txt
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.