Cen Jung Tjhai writes: >>And I think if the IKE_SA_INIT messages grow too large with QSKE, >>then it’s better to develop generic fragmentation mechanism for >>IKE_SA_INIT, rather than making it specific for fragmenting QSKE >>blobs. Generic mechanism would allow to reuse it in case we’ll have >>to include other large payloads in initial messages. > > Yes, while a generic mechanism would allow it to be reused, it > sounds like a different draft all together. It could result in a > very complex change in the protocol. Furthermore, we would like to > support QSKE blob that is larger than 64KB in size, hence we > fragment it in that way.
Actually I think it would be better NOT to change IKE_SA_INIT at all, but instead add new exchange between the IKE_SA_INIT and IKE_AUTH. I.e., lets have following exchange: Initiator Responder ------------------------------------------------------------------- HDR(IKE_SA_INIT, MID=0), SAi1, KEi, Ni, N(IKEV2_FRAGMENTATION_SUPPORTED), N(PRE_AUTH_SUPPORTED) --> <-- HDR(IKE_SA_INIT, MID=0), SAr1, KEr, Nr, N(IKEV2_FRAGMENTATION_SUPPORTED) N(PRE_AUTH_NEEDED), [CERTREQ] HDR(PRE_AUTH, MID=1), SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...} --> HDR(PRE_AUTH, MID=1), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...} --> ... HDR(PRE_AUTH, MID=1), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...} --> <-- HDR(PRE_AUTH, MID=1), SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...} <-- HDR(PRE_AUTH, MID=1), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...} ... <-- HDR(PRE_AUTH, MID=1), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...} HDR(IKE_AUTH, MID=2), SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR(IKE_AUTH, MID=2), SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} I.e., we run normal IKE_SA_INIT with message ID of 0. It negotiates the fragmentation (IKEV2_FRAGMENTATION_SUPPORTED), so all further exchanges after IKE_SA_INIT can use fragmentation. Then we do another exchange before the IKE_AUTH, i.e. we do PRE_AUTH exchange before IKE_AUTH using message id 1 (or even message ids 2, 3, 4, etc, as many as are needed). This step does the large blob exchange neede for the IKE_AUTH. As these are normal fragmented IKEv2 message, i.e. there is request and there is reply. What goes in there is most likely using some new payload number to transfer the QSKE data in both directions. Note, that IKEv2 messages are limited to 4GB in size, and one payload inside IKEv2 message is limited to 64kB in size, so if larger than 64k objects need to be transmitted, it can be transmitted using exactly one IKEv2 message, having multiple payloads in it. On the other hand as fragments are not individually acknowledged, we do not want to transfer too big messages using it, so it might be better to allow multiple PRE_AUTH message exchanges before moving to the IKE_AUTH. This means that the PRE_AUTH exchange most likely needs to have some way of telling the other end when it is done, and when to move to IKE_AUTH. IKE_AUTH then would be just normal IKE_AUTH. The fact whether we need the PRE_AUTH exchange can be negotiated in the IKE_SA_INIT, either using transform types in SA payload, or using the notify payloads. Also if we split data to less than 64k chunks anyways, it might also be better not to use IKEv2 fragmentation, but instead just send several PRE_AUTH exchanges instead. Note, that the PRE_AUTH happening between IKE_SA_INIT and IKE_AUTH would be encrypted, and MACed, but it WILL NOT be authenticated, i.e., we have not yet authenticated the other peer, and we will not include those octets to the AUTH payload calculations, so they will not be authenticated in AUTH phase, like the IKE_SA_INIT contents will be authenticated. I think this kind of step between IKE_SA_INIT and IKE_AUTH might be easiest and most generic way of transferring the QSKE data. We will be transferring large amount of data anyways, so trying to put it part of IKE_SA_INIT is not useful, and trying to play around with cookies, and IKE_SA_INIT modifications is just adding complexity. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec