Hi, > I think the best way to make them work is to keep the individual > payload length less than 64k, but QSKE (or whatever the new payload is > called) so that it can provide separate pieces of actual KE payload.
That's exactly what I suggested in https://mailarchive.ietf.org/arch/msg/ipsec/jahWqh_dvPkqAXnA4-C9LndtWWk > This way we also get acks etc for each piece, and if there is errors > we do not need to resend the whole n MB message, but instead we resend > (and reassemble and buffer) <64kB piece of the KE inside one > fragmented ike exchange. > > I.e. instead of having: > > Original Message: > > HDR(MID=n), SK(NextPld=PLD) {PLD(2MB)} > > Fragmented Message: > > HDR(MID=n), SKF(NextPld=PLD, Frag#=1, TotalFrags=128) > {first 16kB of PLD} --> > HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=128) > {next 16kB of PLD } --> > ... > HDR(MID=n), SKF(NextPld=0, Frag#=128, TotalFrags=128) > {last 16kB of PLD} --> > > <-- HDR(MID=n) response ack > > (and here would need to assume that 16kB UDP packet would get properly > IP-fragmented as IKE fragmentation supports only at maximum of 255 > fragments). No, IKE fragmentation allows to have up to 2^16 fragments, so it possible to transfer up to ~60MB of key data with no IP fragmentation (assuming each IKE fragment contains ~1000 bytes of key data). > We could do something like this: > > HDR(MID=n), SKF(NextPld=PLD, Frag#=1, TotalFrags=16) > {first 1kB of PLD(0/128, first 16kB of PLD)} --> > HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=16) > {next 1kB of PLD(0/128, first 16kB of PLD)} --> > ... > HDR(MID=n), SKF(NextPld=0, Frag#=16, TotalFrags=16) > {last 1kB of PLD(0/128, first 16kB of PLD)} --> > > <-- HDR(MID=n) ACK > > HDR(MID=n+1), SKF(NextPld=PLD, Frag#=1, TotalFrags=16) > {first 1kB of PLD(1/128, next 16kB of PLD)} --> > HDR(MID=n+1), SKF(NextPld=0, Frag#=2, TotalFrags=16) > {next 1kB of PLD(1/128, next 16kB of PLD)} --> > ... > HDR(MID=n+1), SKF(NextPld=0, Frag#=16, TotalFrags=16) > {last 1kB of PLD(1/128, next 16kB of PLD)} --> > > <-- HDR(MID=n+1) response ack > ... > HDR(MID=n+128), SKF(NextPld=PLD, Frag#=1, TotalFrags=16) > {first 1kB of PLD(128/128, last 16kB of PLD)} --> > HDR(MID=n+128), SKF(NextPld=0, Frag#=2, TotalFrags=16) > {next 1kB of PLD(128/128, last 16kB of PLD)} --> > ... > HDR(MID=n+128), SKF(NextPld=0, Frag#=16, TotalFrags=16) > {last 1kB of PLD(128/128, last 16kB of PLD)} --> > > <-- HDR(MID=n+128) response ack > > I.e., we use normal IKEv2 fragmentation and send for example 16kB > pieces in each of the IKE_AUX exchange, but we have multiple IKE_AUX > exchanges, and each of them will deliver one piece of the full QSKE to > the other end, so if each piece is 16 kB, we will have 128 of those > 16kB pieces. > > The normal fragmentation code will not be changed and IKEv2 exchanges > are still processed normally without any special handling, only think > that requires special handling is the QSKE payloads which can contain > multiple pieces where each piece is delivered in separate exchange. > > There are some other complications if responder also needs to send > large things back, thus the initiator needs to know to do empty > requests to responder until final pieces of the responders QSKE > arrives (in case responders QSKE was bigger than initiators). Or probably change roles for a while and make the responder to initiate a reverse requests to transfer its large KE to initiator. Not sure it is better though... If the particular QSKE is DH-like (assuming that initiator's and responder's public keys are of the same size and are computed independently), then the much better approach is possible: HDR (IKE_AUX, MID = 1), SK {KE(1st piece of initiator's public key)} --> <-- HDR (IKE_AUX, MID = 1), SK {KE(1st piece of responder's public key)} HDR (IKE_AUX, MID = 2), SK { KE(2nd piece of initiator's public key)} --> <-- HDR (IKE_AUX, MID = 2), SK {KE(2nd piece of responder's public key)} HDR (IKE_AUX, MID = 3), SK {KE(3rd piece of initiator's public key)} --> <-- HDR (IKE_AUX, MID = 3), SK { KE(3rd piece of responder's public key)} .... HDR (IKE_AUX, MID = 3), SK {KE(last piece of initiator's public key)} --> <-- HDR (IKE_AUX, MID = 3), SK { KE(last piece of responder's public key)} Pieces can be made very small to avoid fragmentation at all, or larger, so that IKE fragmentation will take place, but the number of fragments each message is divided info is small, so that the initiator would not need to resend large amount of data in case of packet loss. Regards, Valery. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
