Questions about IPsec and Netfilter

Questions about IPsec and Netfilter

[Alan Stern]

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?

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?

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?

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

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

Alan Stern

Re: Questions about IPsec and Netfilter

[Patrick McHardy]

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.

Re: Questions about IPsec and Netfilter

[Lennart Sorensen]

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

Re: Questions about IPsec and Netfilter

[Herbert Xu]

Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> Q4: Is it true that NAT-Traversal isn't implemented for transport mode?

NAT-Traversal works in transport mode but you have the standard problem
that if you've got two peers behind one IPsec gateway then they'll look
the same to you.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt