[Openswan Users] Grief and nonsense with fragmentation

Marcus D. Leech mleech at nortel.com
Thu Mar 3 22:44:00 CET 2005


I ran into fragmentation issues this evening, which were "solved" by making
  shorter certificates (1280-bit keys, instead of 2048).  But I'm very puzzled
  by the behaviour.

Over the path to the server, I was easily able to PING with 4000-byte packets,
which
  clearly needed to be fragmented, and you could see my roadwarrior fragmenting
them
  at source, and them getting re-assembled on the server/gateway, and being
responded to
  appropriately.

But IKE seemed to run into trouble with longer certificates, and when I put a
TCP dump
  on it, it seemed that it wanted to send a 1580-byte packet, and TCPDUMP
claimed
  a mismatch between the UDP length declared, and the IP length
(UDP:1580/IP:1472).  The
  flags[] field in TCPDUMP indicated [+], which means more fragments to follow,
but
  there were never any more fragments (maybe due to the apparent length
mismatch?).
  I noticed that other IKE packets had their DF bit set--which would have caused
  problems for anything longer than the path MTU.  Presumably, the packets
carrying
  certificates have DF turned off, but whatever code handles that case is not
quite right,
  since there's a slightly-bogus packet emitted with the "more fragments to
follow" bit turned
  on, but no more fragments ever turned up.  Could be a kernel bug, but I'll
observe
  that PING seems able to cause a fragmented packet train to be handled
correctly
  by the kernel.  Maybe when you turn off DF in a socket that previously had DF
  turned ON, things get confused in the network stack?

I also noticed that IKE packets would show up in TCPDUMP with bad UDP checksums,
  but not all of them.

Also, when sending actual traffic in ESP, one direction would have DF set on the
ESP
  datagrams, and the other wouldn't.  This is between systems running identical
kernels,
  OpenSwan, and userland configuration (FC3).  This has me puzzled, since I
don't
  think routers are allowed to mess with the DF bit.

-- 
Marcus Leech                Mail:   Dept W669, M/S: 04352P16
Advisor                     Phone: (ESN) 393-9145  +1 613 763 9145
Internet & Security Services
Nortel Networks                          mleech at nortelnetworks.com


More information about the Users mailing list