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: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> Tero Kivinen
> Sent: Tuesday, April 21, 2009 15:48
> To: ipsec@ietf.org
> Subject: [IPsec] Some comments to draft-ietf-ipsecme-ikev2-resumption-
> 02.txt
>
> 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.
> --
> kivi...@iki.fi
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
