>Number:         21209
>Category:       kern
>Synopsis:       ipfilter should see ipsec packets after decryption, not before
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 17 06:29:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Curt Sampson
>Release:        NetBSD 1.6R 2003-04-10
>Organization:
>Environment:
System: NetBSD ironic.cynic.net 1.6R NetBSD 1.6R (IRONIC-$Revision: 1.7 $) #1: Thu Apr 17 13:19:38 JST 2003 cjs@ironic.cynic.net:/u/netbsd/src-current/sys/arch/i386/compile/IRONIC i386
Architecture: i386
Machine: i386
>Description:
According to PR 11844, the current processing flow for packets is:

    ---> ip_input --> pfil_hooks ---> ipsec processing
    ---> ip_output --> ipsec processing ---> pfil_hooks
    ---> ip6_input --> pfil_hooks ---> ipsec processing
    ---> ip6_output ---> ipsec processing ---> pfil_hooks

There are situations in which you are exchanging IPSec encrypted traffic
with an untrusted host; a typical example would be running IPSec in
tunnel mode between your company's router and that of another company
that is a partner or a client. In this case, there are two problems that
arise from this processing order:

1. It is impossible to use ipfilter to protect your gateway. IPSec can
see only that there are encrypted packets destined to your machine; it
can't examine the packets to allow or deny any traffic. In particular,
in tunnel mode it can't check to see that the remote end is not forging
source IP addresses.

2. For hosts behind the gateway, we have no protection from the
untrusted host sending packets with forged source addresses, since
we can't block them on the incoming interface, and when they reach
an outgoing interface, we no longer know what incoming interface the
packets came from. As well, protection in general becomes much more
difficult since we have to take what would be one rule on the incoming
interface and duplicate it on all outgoing interfaces.

In that same PR, itojun suggests that this would be a better flow:

    ---> ip_input --> ipsec processing ---> pfil_hooks
    ---> ip_output --> pfil_hooks ---> ipsec processing
    ---> ip6_input ---> ipsec processing ---> pfil_hooks
    ---> ip6_output --> pfil_hooks ---> ipsec processing

I agree.

>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: