kern/123793: [ipsec] [patch] KAME IPSEC does not pass processed packets to pfil hooks

[Eugene Grosbein]

>Number:         123793
>Category:       kern
>Synopsis:       [ipsec] [patch] KAME IPSEC does not pass processed packets to pfil hooks
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun May 18 13:40:02 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     Eugene Grosbein
>Release:        FreeBSD 6.3-STABLE i386
>Organization:
Svyaz-Service JSC
>Environment:
System: RELENG_6

>Description:
	(This issue applies to RELENG_6 only, as newer versions
	do not contain KAME IPSEC implementation anymore.)

	When AH, ESP or IPCOMP protocols finish packets processing,
	they pass them directly to pr_input() for appropriate
	encapsulated protocol. Thus, it is not possible to filter
	incoming packets processed with this IPSEC implementation
	after they has been decrypted.

	Let's consider simple schema:

L-R+G-Internet

	Here R is a router (FreeBSD 6.3), L is a host in its LAN
	using private IP-addresses (RFC 1918).
	Plus sign designates provider's radio-ethernet segment built with
	L2 radio-bridges, G is provider's gateway to the Internet.
	R and G use public IP-addresses within radio-ethernet,
	so R does NAT for L.

	There is also another host H in the same radio-ethernet segment,
	in the same IP-network as R and G, it has public IP-address.
	We need to protect traffic between R and H so run IPSEC on R and H.
	It works nice for traffic running between R and G.

	Now let's see what happens when L connects to H.
	Outgoing packet from L goes through NAT on R,
	translated packet then goes through IPSEC and finally reaches H.
	Now H sends its encrypted reply that reaches R that decrypts it.
	But IPSEC does not pass decrypted packed downto ip_input(),
	it passes it to pr_input() directly so H's reply gets delivered
	locally instead of being NAT'ed and forwarded.
	Finally, it is dropped.

	Kernel option IPSEC_FILTERGIF should help in this case
	but it does not.

	Newer FAST_IPSEC implementation does not have this problem,
	it passes decrypted answer to ip_input() via netisr,
	so it reaches pfil hooks and may be processed with NAT
	and then routed successfully.

	However, switching to FAST_IPSEC is not an option when
	we require working IPCOMP support. See this PR for details:
	http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/123587

	So, the solution is to make kernel option IPSEC_FILTERGIF
	to cover this case and pass decrypted incoming packet
	again to ip_input() via netisr just like FAST_IPSEC does,
	thus bringing old implementation's behavour more in line
	with new one.

>How-To-Repeat:
	See description
>Fix:

	The patch is pretty small and simple:

	ftp://www.kuzbass.ru/pub/freebsd/patches/ipsec-filter.diff.gz
>Release-Note:
>Audit-Trail:
>Unformatted: