5.3 IPSEC broken

[Robert Watson]

On Sat, 25 Sep 2004, Robert Watson wrote:

> On Sat, 25 Sep 2004, Hannes Mehnert wrote:
> 
> > On Fri, Sep 24, 2004 at 10:58:33PM -0400, Robert Watson wrote:
> > > I'd like to take a look at this sometime in the next few days.  Could you
> > > send me an appropriately censored version of your racoon configuration for
> > > each endpoint that I can use as a starting point?
> > 
> > Sure, my config files are available at https://berlin.ccc.de/~hannes/racoon/
> > 
> > I use a /30 subnet for IPSec, 192.168.2.40/30.
> 
> So an interesting first observation for anyone else following this is
> that under mbuma, the number of bytes available in an mbuf has changed
> by four due (presumably) to the use of extra space by mbuma: 

A bit more follow-up in case anyone else starts chasing this also: ktrace
indicates that it's this sendto:

   621 racoon   GIO   fd 3 wrote 108 bytes     
       "<31>Sep 25 15:03:37 racoon: 2004-09-25 15:03:37: DEBUG:
pfkey.c:1061:p\
        k_sendupdate(): call pfkey_send_update"
   621 racoon   RET   sendto 108/0x6c
   621 racoon   CALL  getpid
   621 racoon   RET   getpid 621/0x26d
   621 racoon   CALL  sendto(0x4,0x809c800,0xd8,0,0,0)
   621 racoon   RET   sendto -1 errno 55 No buffer space available
   621 racoon   CALL  gettimeofday(0xbfbfe818,0)
   621 racoon   RET   gettimeofday 0
   621 racoon   CALL  write(0x1,0x80a2000,0x72)
   621 racoon   GIO   fd 1 wrote 114 bytes
       "2004-09-25 15:03:38: ERROR: pfkey.c:1076:pk_sendupdate(): libipsec
fai\
        led send update (No buffer space available)

That's a 216 byte packet, fwiw.  I instrumented key.c and ran into the
following ENOBUFS case on key.c:6957:

        /* align the mbuf chain so that extensions are in contiguous region. */
        error = key_align(m, &mh);
        if (error)
                return error;
 
        if (m->m_next) {        /*XXX*/
                m_freem(m);
                return ENOBUFS;
        }

I.e., the author knew it was a bug (feature) that an additional mbuf
couldn't be handled here, but we do need to handle one.  Looks like much
of the surrounding code could be replaced with a call to m_defrag() and/or
m_pullup().

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Principal Research Scientist, McAfee Research