Hi Paul,
> 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).
I still think that's not right. A responder might know that it is
connected to a network with mtu issues. It should be able to skip the
failure of the first response packet not making it by starting out with
fragmenting (in ikev1 terms that would be ike_frag=force).
I think either end should be able to start fragmentation. Once an
endpoint receives a full fragmented packet correctly, it should also
send back using fragments.
While I agree with you that ability to start using fragmentation by
responder
without waiting for fragmented message from initiator is useful
in some situations, I still think that in general it is initiator who should
turn this option on. In most situations peers will first try to send
unfragmented message in hope that it will pass. In this case
it is not reliable to rely on responder's logic when to turn
fragmentation on, as responder may only respond to retransmitting
messages and it doesn't know how many retries initiator will do.
So it may decide to fragment message too late. The only exception -
the situation you described, when responder always sends messages
fragmented. I think we may add this exception to responder's logic.
>> 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.
I already think authenticated fragments is adding a lot of
logic. Let's not add more. Optimising on size is pointless, just
fragment near the minimum packet size. It's going to add what? 1 more
fragment?
I also think that PMTU discovery isn't very useful for IKE.
That's why it is MAY. I just don't like hardcoded values for message size,
especially 576 bytes, as I couldn't find in the RFCs that
IP datagrams of this size will pass anywhere. So, in my mind, we don't have
safe low limit for IPv4. That's why I leave a small backdoor -
PMTU discovery, that is not limited to any predefined value.
> 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.
The word "number" and "id" is confusing in the IKEv1 version. I'm not
sure what you are referring to here (I have to re-read the entire draft
to give feedback before vancouver)
The IKEv1 fragment id is never used. All real world implementations
always set it to 1 AFAIK. A peer never really has more then one
fragmented IKE packet outstanding with a peer. Perhaps that is different
in v2?
There is no field "id" in IKEv2 Fragmentation Payload - just Fragment Number
and Total Fragments. But Total Fragments field plays a dual role if
peer uses PMTU discovery - i.e. tries several fragment sizes.
In this case Total Fragments allows to distinguish between fragments from
different sets (assuming that trying smaller fragment size results in
increasing number of fragments).
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
