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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 10 May 2007 17:29:00 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Alan Stern <stern@...land.harvard.edu>
CC:	Networking development <netdev@...r.kernel.org>
Subject: Re: Questions about IPsec and Netfilter

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?


Similar to regular tunnels, hooks occur

at output:

(plain packet) NF_IP_LOCAL_OUT/NF_IP_FORWARD -> NF_IP_POST_ROUTING
IPsec
(encapsulated packet) NF_IP_LOCAL_OUT -> NF_IP_POST_ROUTING

at input:

(encapsulated packet) NF_IP_PRE_ROUTING -> NF_IP_LOCAL_IN
IPsec
(plain packet) NF_IP_PRE_ROUTING -> NF_IP_LOCAL_IN/NF_IP_FORWARD

> 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?


At output not, at input decapsulated tunnel mode packets go through
the stack again. In transport mode it only goes through the netfilter
hooks again, except when it is rerouted, in which case it is passed
to dst_input again.

> 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?


It can't determine that a packet has been encapsulated afterwards,
before it can look at skb->dst->xfrm. For decapsulated packets
it looks at skb->sp.

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


The code seems to support it, altough I don't think I've ever tried it.

> 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?


Sort of, the end of the policy list is treated as "no ipsec" policy.
Strictly speaking this seems to be a violation, but I haven't seen
any other implementation that behaves differently.
-
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