On Fri, 4 Oct 2013, Valery Smyslov wrote:
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.
The goal is to reduce latency and retransmissions. On mobile devices
with an "always on" VPN, that is really important. (i.e. my iphone is
failing at that terribly, but for other reasons)
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?
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?
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
