[Swan] ike_frag= options - what should it mean and do?

[Paul Wouters]

Hi

So we implemented IKE fragments, but there are some unanswered questions
on the design when the options don't match up. We have to make some
decisions, for which I would like some input from others.

currently we have:

ike_frag=no|yes|force with the default being yes

- When yes or force, send the FRAGMENTATION vendorid
- When yes, on retransmit for packets > FRAG_LEN, send in fragments
- when force, don't wait for retransmit, do it right away (and don't care about seeing vendorid)
- When no, don't send vendorids, dont send fragments (but assemble
   received fragments)

These do not seem the right choices now that we are doing some tests

Image your roadwarrior "road" knows it is on bad a network. It can set
ike_frag=force so it does not have to wait on that one retransmit. But
the other end does not use force, so on its answer, there is a still a
packet being lost and re-transmitted. This could be resolved if we not
only remember receiving a vendorid, but also remember if the peer has
sent us fragments. If so, we should probably assume the link problem is
symmetrical and fragment immediately instead of waiting on a retransmit.

My thoughts right now are leaning towards:

- Never ignore vendorid. If we don't see it from the peer, don't send
   fragments.
- When using force, fragment without waiting for a retransmit
- When using yes, fragment when retransmitting if vendorid was seen, or
   fragment immediately when we received fragments from the peer already.
- When using no, don't send fragmentation vendorid and don't send
   fragments. (be Postel on receiving fragments)

There is the corner case of not seeing a vendorid but receiving
fragments. I don't know of any such implementations. However, currently
we never refuse to assemble fragments, even if we did not see a
vendorid. This _could_ become a security issue, although the code is
pretty restrictive. We don't allow more then 16 fragments before giving
up. Worst case they give us a 552*16 garbled IKE packet, but they might
as well send us 1500+ byte garbled IKE packets...

What racoon has for yes/no/force is kinda strange to me:

              ike_frag (on | off | force);
                      Enable receiver-side IKE fragmentation if racoon(8) has been built with this feature.  If set to on, racoon will
                      advertise itself as being capable of receiving packets split by IKE fragmentation.  This extension is there to
                      work around broken firewalls that do not work with fragmented UDP packets.  IKE fragmentation is always enabled
                      on the sender-side, and it is used if the peer advertises itself as IKE fragmentation capable.  By selecting
                      force, IKE Fragmentation will be used when racoon is acting as the initiator even before the remote peer has
                      advertised itself as IKE fragmentation capable.

Having the on/off be different for receiver/sender seems weird to me.

Note that on the first packet of an exchange, we cannot reassmble
because we have no state object to match it with, so we currently
don't support that and the packet is lost. However, the first packet
is never that big, and if you cannot do UDP packets of say 1200 MTU,
then even establishing the tunnel will be pretty useless, as all traffic
in that tunnel will hit an even worse MTU limit (due to ESPinUDP and
tunnel mode overhead)

Thoughts?

Paul