[Swan] fragment assembly code handling of non ESP marker

[Paul Wouters]

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

> Can the first fragment contain a non ESP marker?
>
> If not, we should delete the code to handle it.
> In programs/pluto/ikev1.c:
>
>        /* Strip non-ESP marker from first fragment */
>        if (md->iface->ike_float && ike_frag->index == 1 && ike_frag->data[0] == 0)
>        {
>            ike_frag->data += 1;
>            ike_frag->size -= 1;
>        }

>From the racoon source:

         /*
          * Do not add the non ESP marker for a packet that will
          * be fragmented. The non ESP marker should appear in
          * all fragment's packets, but not in the fragmented packet
          */

and

         /* If NAT-T port floating is in use, 4 zero bytes (non-ESP marker)
            must added just before the packet itself. For this we must
            allocate a new buffer and release it at the end. */

> If it can happen, we should fix the code.  This code assumes that the
> marker is 1 octet long but it is 4 octets.

The racoon code uses some macros around sizeof structs, but they build
the packets quite differently from us.

When an IKE packet is build and then send out over NAT-T, the marker has
to be added to distinguish this port 4500 packet to be an IKE packet,
and not an ESPinUDP packet. What the comments suggest is that racoon,
once it builds this udp 4500 packet, then has to chop it in pieces, and
remove that original non-esp marker. Each fragment then is made with the
non-esp fragment so all port 4500 (fragmented) IKE packets are not
treated as ESPinUDP.

I'm not seeing where we add the non-esp marker in our nat-t code though,
so see if it is in the path and we need to remove it as the code above
suggests.

Paul