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
