xfrm_larval_drop required for bind over ipsec

[Matt LaPlante]

On Fri, Apr 18, 2008 at 11:44 AM, Kevin Darcy <kcd at chrysler.com> wrote:
>
> Matt LaPlante wrote:
>  > I wanted to follow up on a problem originally reported in this thread
>  > [http://marc.info/?t=119826505600004&r=1&w=2].  Running bind 9.4.1,
>  > when zone transfers are to happen over an ipsec connection, but the
>  > ipsec connection goes away, named effectively stops working on all
>  > interfaces.
>  >
>  > After tracking down a redhat bug that confirmed the issue
>  > [https://bugzilla.redhat.com/show_bug.cgi?id=427629] I forwarded the
>  > problem on to the lkml, and David Miller quickly suggested the
>  > following [http://lkml.org/lkml/2008/4/17/478]:
>  >
>  > echo "1" >/proc/sys/net/core/xfrm_larval_drop
>  >
>  > This does appear to fix the issue.  The problem is that
>  > xfrm_larval_drop defaults to 0 in newer kernels, which apparently
>  > causes io over an ipsec connection block when the link is unavailable.
>  >  It would seem bind, at least as of 9.4.1, does not anticipate this
>  > behavior, and hangs rather dramatically in the process.
>  >
>  Hmmm... how exactly is BIND supposed to "anticipate" that a socket which
>  is set to non-blocking will in fact sometimes block, if the connection
>  is an IPsec one which happens to be in a "larval" state at some
>  particular point in time? What should BIND do differently to cope with
>  this scenario? Some guidance from the kernel developers and/or IPsec
>  gurus might be helpful.

I have no idea.  I'm not a kernel developer, so I have no clue what
they expect to be happening at the application level.  It has been
brought up once before (that I could find) where someone suggested
making the default behavior the one suggested here, but it was
rejected for reasons that are unclear to me.  Thread here:

http://lkml.org/lkml/2007/12/4/260

>
>  For some odd reason, "larval" makes me think of "bug". But maybe that's
>  just me...

Not just you. :)

>
>
>                   - Kevin
>
>
>
>