NetBSD Problem Report #21209

Received: (qmail 3514 invoked by uid 605); 17 Apr 2003 06:28:13 -0000
Message-Id: <20030417062808.CA73B32F38@ironic.cynic.net>
Date: Thu, 17 Apr 2003 15:28:08 +0900 (JST)
From: cjs@cynic.net
Sender: gnats-bugs-owner@netbsd.org
Reply-To: cjs@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: ipfilter should see ipsec packets after decryption, not before
X-Send-Pr-Version: 3.95

>Number:         21209
>Category:       kern
>Synopsis:       ipfilter should see ipsec packets after decryption, not before
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    ipf-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 17 06:29:00 +0000 2003
>Closed-Date:    
>Last-Modified:  Tue Sep 05 23:08:07 +0000 2006
>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:

From: itojun@iijlab.net
To: cjs@ironic.cynic.net
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/21209: ipfilter should see ipsec packets after decryption, not before 
Date: Thu, 17 Apr 2003 16:52:06 +0900

 >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

 	see http://www.netbsd.org/Documentation/network/ipsec/
 	for the correct flow.  the above is not what is implemented at this
 	point.

 >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

 	no, i don't think i suggested it is better.  see the above URL.

 	what is lacking (in all packet-filtering packages available) is the
 	ability to describe which header it would like to filter on, inner or
 	outer (in generic sense, there can be more than 2 layers of
 	encapsulation so "inner/outer" is not enough).

 itojun

From: itojun@iijlab.net
To: cjs@ironic.cynic.net, gnats-bugs@gnats.netbsd.org
Cc:  
Subject: Re: kern/21209: ipfilter should see ipsec packets after decryption, not before 
Date: Thu, 17 Apr 2003 16:54:00 +0900

 >>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
 >
 >	see http://www.netbsd.org/Documentation/network/ipsec/
 >	for the correct flow.  the above is not what is implemented at this
 >	point.

 	err, remove "the above is...".

 itojun

From: Andrew Doran <ad@interlude.eu.org>
To: itojun@iijlab.net
Cc: cjs@ironic.cynic.net, gnats-bugs@gnats.netbsd.org
Subject: Re: kern/21209: ipfilter should see ipsec packets after decryption, not before
Date: Thu, 17 Apr 2003 13:49:09 +0100

 OpenBSD has an 'enc' pseudo-interface that sees the decrypted traffic. That
 would be useful in the general case (i.e. this one) and also useful for
 routing. Has something like this been considered?

 Andrew

From: itojun@iijlab.net
To: Andrew Doran <ad@interlude.eu.org>
Cc: cjs@ironic.cynic.net, gnats-bugs@gnats.netbsd.org
Subject: Re: kern/21209: ipfilter should see ipsec packets after decryption, not before 
Date: Fri, 18 Apr 2003 10:47:01 +0900

 >OpenBSD has an 'enc' pseudo-interface that sees the decrypted traffic. That
 >would be useful in the general case (i.e. this one) and also useful for
 >routing. Has something like this been considered?

 	has been considered but rejected for the same reason (scope information
 	will be lost when IPv6 traffic goes to "enc" device).

 	openbsd IPv6 IPsec does not use "enc" device.

 itojun
Responsible-Changed-From-To: kern-bug-people->darrenr
Responsible-Changed-By: darrenr@netbsd.org
Responsible-Changed-When: Thu, 08 Dec 2005 11:18:26 +0000
Responsible-Changed-Why:


Responsible-Changed-From-To: darrenr->kern-bug-people
Responsible-Changed-By: wiz@netbsd.org
Responsible-Changed-When: Sun, 03 Sep 2006 01:06:25 +0000
Responsible-Changed-Why:
Back to role account, darrenr doesn't have commit access any longer.


Responsible-Changed-From-To: kern-bug-people->ipf-bug-people
Responsible-Changed-By: wiz@netbsd.org
Responsible-Changed-When: Tue, 05 Sep 2006 23:08:07 +0000
Responsible-Changed-Why:
New role account for IPF bugs.


>Unformatted:

Home	PR Database Search