In message <rmiek1vclk3.fsf@fnord.ir.bbn.com>
Greg Troxel writes,

>jonathan@dsg.stanford.edu writes:
>
>> I think it's best to put the test for "no IPsec active, therefore none
>> needed" directly into ip_input() and ip6_input().
>> 
>> I'm not sure about forwarding, I'd have to look.  If dimming memory
>> serves, the API from ipsec[46]_in_reject() *always* returns a non-NULL
>> policy, so what you'd want is to check for only the default policy
>> existing, and if so, skip all the ipsec*_in_reject goop completely.
>
>And a check that the system default policy is USE or NONE; if it's
>REQUIRE IPsec processing is still needed.  It may make sense to
>maintain variable omit_ipsec which is 1 if the conditions for doing so
>are met (empty SPD, empty SAD, default policy use or none, I think),
>and have SPD/SAD/sysctls update the variable, maintaining the invariant.

Yes,that's one large reason why I suggested to Christos that he
encapsulate the exact check inside an inline function.

Finding the correct check(s) requires some thought, and so it's
clearly worthwhile encapsulating that check, or checks, in a function,
for all the obvious reasons.  (Maintenance, ease of understanding,
expanding the check from a simple global to something slightly more
complex...).

Also, that way, the internal globals inside KAME IPSEC and FAST_IPSEC
can diverge (should they ever do, from ongoing
maintenance/chagnes/whatever), as long as the function stays the same