netdev - Re: Questions about IPsec and Netfilter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070510154326.GB8754@csclub.uwaterloo.ca>
Date:	Thu, 10 May 2007 11:43:26 -0400
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Networking development <netdev@...r.kernel.org>
Subject: Re: Questions about IPsec and Netfilter

On Thu, May 10, 2007 at 10:36:14AM -0400, Alan Stern wrote:
> I've got a few questions about the relationship between the IPsec 
> implementation and Netfilter.
> 
> Q1: At what points during packet processing do the IPsec transformations 
> occur?  In particular, which netfilter hooks do they come before and 
> after?  And likewise, which routing operations do they come before and 
> after?

Are you using netkey or klips?

> Q2: When a packet using IPsec tunnel mode is encapsulated or 
> de-encapsulated, does the newly-formed packet return to some earlier point 
> in the stack for further netfilter processing or routing?  What about 
> transport mode?

As far as I can tell the encrypted packet goes in the INPUT chain, then
is decrypted and goes back in either INPUT or FORWARD depending on the
unencrypted source/destination.  Well for netkey anyhow.  klips goes in
the INPUT chain and then is decrypted and then comes in the ipsecX
interface either on INPUT or FORWARD chains.

> Q3: How can iptables rules determine whether they are dealing with a 
> packet which has been de-encapsulated from (or encapsulated within) an 
> IPsec wrapper?

If using netkey, and 2.6.16 or newer, then the policy tag will be ipsec
if it was decrypted from an ipsec tunnel.  I recently had to upgrade to
shorewall 3.x to deal with that when I wnet to using netkey and 2.6.18
kernel together.  With klips the packets from an ipsec tunnel arive on
the ipsecX interface after being decrypted so you can recognize them
that way.

> Q4: Is it true that NAT-Traversal isn't implemented for transport mode?

No idea.

> In RFC 2401 (Security Architecture for the Internet Protocol), section 5
> includes this text:
> 
>    As mentioned in Section 4.4.1 "The Security Policy Database (SPD)",
>    the SPD must be consulted during the processing of all traffic
>    (INBOUND and OUTBOUND), including non-IPsec traffic.  If no policy is
>    found in the SPD that matches the packet (for either inbound or
>    outbound traffic), the packet MUST be discarded.
> 
> But on Linux systems, by default the SPD is normally empty (as shown by
> "setkey -DP") and all packets are allowed to pass unhindered.
> 
> Q5: Isn't this a violation of the RFC?  Or is there some implicit policy 
> entry which accepts all packets without applying any security association?
> 
> Thanks for any answers.  I may think up more questions later...

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html