Hi Yaron,
If Responder receives IKE Fragment Message after it received, successfully
verified and processed regular message with the same Message ID, it means
that response message didn't reach Initiator and it activated IKE
Fragmentation. If Fragment Number in Encrypted Fragment Payload in this
message is equal to 1, Responder MUST fragment its response and retransmit
it back to Initiator in fragmented form.
I think the MUST in the second sentence is incorrect. Assume the sender
switched to fragmented form, but the responder knows that it sent a very
short response. The response got lost, but this is unrelated to
fragmentation. So the responder should simply retransmit it as-is, and
there's no reason to fragment it.
The idea is that it is Initiator who decides whether to use fragmentation or
not,
as only he/she is responsible for retransmissions. Responder is just a
"slave".
And for simplicity we assume that either both use fragmentation or both
don't.
It is stated in the beginning of Page 5: "Responder MUST send response
message
in the same form (fragmented or not) as corresponded request message."
You are right that it may lead (and actually leads) to "false positive"
decisions to use fragmentation in situations when it actually can't help.
We may change this logic as follows:
Responder MUST fragment its response if it is greater than
Responder's fragmentation threshold and SHOULD NOT do it otherwise.
Is it OK? In this case the requirement for Responder to use the same
form should also be changed to SHOULD (or removed completely).
Also I'm not happy with the first part of the new text (last paragraph of
Sec. 2), which adds complexity for both sender and responder. The sender
must ensure that when it re-fragments the message, the fragment count is
indeed higher (so it cannot use a simple table of possible fragment
sizes). And the receiver must add the number of fragments into its
IKE-level retransmit logic. I understand why this might be needed
sometimes, but is the added flexibility (allowing to retry different
fragment sizes) worth the complexity?
That is the question. This is only for PMTU discovery. Still waiting for WG
members
to discuss whether it is needed. And anyway all this functionality is marked
as MAY.
"MUST" for ensuring that fragments number is increased after
refragmenting is just for fo desire "to be on the safe side" - in real life
it will almost always be increased as IKE PMTU discovery is coarse-grained:
if you decrease fragment size in half you will get twice as many fragments.
And there's no need for IKE to perform fine-grained PMTU discovery, if any.
What about the need for responder to take fragments number
into consideration, - I don't think it will complicate implementation,
just one more field to compare.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
