[Swan] fragment assembly code handling of non ESP marker

D. Hugh Redelmeier hugh at mimosa.com
Fri Feb 15 06:16:28 EET 2013


| From: Paul Wouters <pwouters at redhat.com>
| To: D. Hugh Redelmeier <hugh at mimosa.com>
| Cc: swan at lists.libreswan.org
| Date: Thu, 14 Feb 2013 22:57:34 -0500 (EST)
| Subject: Re: [Swan] fragment assembly code handling of non ESP marker
| 
| On Thu, 14 Feb 2013, D. Hugh Redelmeier wrote:
| 
| > Can the first fragment contain a non ESP marker?

What I meant is:

Clearly each actual udp packet must contain the non ESP marker (if
we're doing port floating).

What I doubted was that the chopped up IKE message needed the marker
when the fragments are well inside the actual UDP packet.

In other words, we send
	marked(fragmented(ikemsg))
not
	fragmented(marked(ikemsg))
because that could not work and not
	marked(fragmented(marked(ikemsg)))
because that seems pointless.

| > If not, we should delete the code to handle it.

That is the conclusion now.

| > 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;
| >        }

Paul fixed this code.  It should be deleted instead.  Unless we've
found brain-dead implementations that put a marker here.  We cater to
brain-dead implementations when they are important.

| >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
|          */

"appear in" would be better phrased as "prefix".

"all fragment's packets" should be "all fragments' packets" or better
"each fragment packet".

"in the fragmented packet" would be better written "prefixiing theIKE
message that is fragmented".

| 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.

I changed the code a few days ago.  Now the marker is added exactly
one place, in send_packet().  Paul just fixed a stupid mistake in that
very code.


More information about the Swan mailing list