Approaches to use IPsec to secure v6-over-v4 tunnels

[Pekka Savola <pekkas@netcore.fi>]

Hi,

This issue has never been fully discussed before, so I thought about 
it a bit.

How do we set up secure v6-over-v4 tunnels (in the control & data
plane security sense) for client <-> tunnel-server communication? How
feasible is this?

I'm mostly interested in investigating whether IPsec could be used as
a "transport mechanism" for traversing NATs or managing the
"configured tunnel end-point setup" when the address is dynamic.  
IPsec may not be feasible in all the scenarios, but if IPsec could be
used to simplify a number of different cases, and security would come
in as bonus, I guess it wouldn't hurt.. :)

Basically, if you need data plane security (i.e., transport security),
we go down to IPsec.  Some control plane security might be manageable 
with ad-hoc mechanisms, such as hashing/keying methods or return 
routability.

Now, as for IPsec, there seem to be two ways to deal with this:

1) IPv4 IPsec tunnel mode with IPv6 payload transform, resulting to:

(In both, I'm excluding the authentication part, or ESP padding.)

IPv4 header - 20 bytes
  ESP header - 8 bytes
    IPv6 header - 40 bytes
      [IPv6 payload]

2) IPv4 IPsec in transport mode with IPv4 transform, resulting to:

IPv4 header - 20 bytes [next-header set to 41: implicit v6-over-v4]
  ESP header - 8 bytes
    IPv6 header - 40 bytes
       [IPv6 payload]

So, both the approaches seem to be equivalent.  Only, the mixed-IP
version transforms, 1), is only supported by a couple of
implementations, while I think 2) is more commonplace.  

2) would additionally require a co-located configured tunnel
management to the IPsec endpoints. If the method was used with dynamic
addresses, this could be quite problematic, unless IPsec provides some
triggers to "reconfigure" the configured tunnel to accommodate new
tunnel-endpoint.  A different approach is having some kind of 
pseudo-interface which would not have these issues, but I think we 
already got out of those... :)

So, the overhead of about 28 bytes compared to 20 of v6-over-v4 
tunnel in IP.

If you encapsulate IPsec in UDP for NAT traversal, that's 8 additional
bytes.  That part is commonly implemented.  Note that NAT traversal
obviously only works when the other end-point has a public address.

It seems a simple deployment for client <-> tunnel-server
communication could be obtained using either mechanism, with 2)
requiring zero implementation, only (rather complex) management for
the tunnel-end point (if dynamic/NAT-traversed) in configured
tunneling.  So, in a sense 1) gives you simplicity when ÍPsec has to
deal with that particular dynamicity complexity.

Are there any flaws or missing points in this analysis?  Thoughts?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings