Hi Tero, thank you for your comments.
A general comment: I think we already decided in the WG that we will
go with the tcp approach, not with this fragmentation layer in the
IKEv2. Why do we have this document here?
As others pointed out this draft is not a WG item.
Some other comments
In section 2.5 the header contains "Total Framgments" field. This
means the initiator must decide the number of framents it is sending
out in the beginning, i.e. it cannot dynamically adjust this if it
sees that it is sending so long fragments that they get lost. It would
be better to use standard way of doing this, i.e. sending the offset
to the start of the fragment, and some kind of indication whether this
was last fragment or not.
Sorry, I see no difference here. Currently draft doesn't allow fragment size
to be adjusted dynamically, as it is easier to implement. But in general
it is possible. When initiator suspects fragments are too big, it would
refragment original packet using smaller value. That will effectively
change fragments number field, that will give responder an indication,
that this is other set of fragments, which will be reassembling in different
fragments list.
Also it is not clear how retransmission is done here at all. I assume
we will send all fragments in case of the retransmission, but again we
Exactly.
cannot adjust the fragment size to be smaller, even if we start to
suspect that there is something between which is eating our fragments.
See above.
Only way to do that would be to delete the IKE SA and start over with
lower fragment size parameter (as it is possible that the responder
did got some of the fragments, for example last one, which was small
enough, and as we only have fragment number, not offset we cannot
know at which offset that packet belongs to).
Even if responder knew offset, what would be the difference?
Regards,
Valery Smyslov.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
