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

[Paul Wouters]

On Thu, 14 Feb 2013, D. Hugh Redelmeier wrote:

I'll answer your email in more detail, but one point:

> Should there be another vendorid that means "please fragment" as opposed
> to the current one that means "you may fragment"?  We should send it in
> case 3 (frag=force). That would allow the other side to know that we think
> fragmentation is required.  In effect, we're negotiating up from frag=on
> to frag=force for the other side.

Isn't that signal coming in by seeing ike fragments? If the initiator is
configured with force/immediate, and we would respond to fragments, it
would be like (assuming frag len of about 1200):

MAIN_I1 ->
         <- MAIN_R1
MAIN_I2 ->
 	<- MAIN_R2
fragments of MAIN_I3 ->
          < fragments of MAIN_R3
MAIN_I4

If we don't make a decision based on receiving fragments, the above
would be:

MAIN_I1 ->
         <- MAIN_R1
MAIN_I2 ->
 	<- MAIN_R2
fragments of MAIN_I3 ->
       [dropped] <- MAIN_R3
          < fragments of MAIN_R3
MAIN_I4

While "yes" causes one initiator packet to be lost, and "force" causes
no initiator packet loss, on the responder I see no reason to bump from
"yes" to "force" mode when we receive fragments. It's a clear signal.

We might then even adopt the policy for rekeys in that instance as well
to prevent further packet loss, but I don't think it is that important,
because you already have an SA up. Losing an IKE packet on rekey is
not causing any packet delay using the existing SA. I think on static
links, people should just set the option correct. And on dynamic links,
you can't really know the situation.

In some way, an initiator on "force" and a responder adapting to seeing
fragments is the most optimal way of establishing the tunnel with the
least amount of latency, which is I think what matters most. Especially
when you think of scaling this within opportunistic encryption
frameworks, where you have an outgoing packet waiting already.

Paul