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

["Bound, Jim" <jim.bound@hp.com>]

We know how to do this we are doing it now on networks.  We don't need the IETF's help.  Yes we have discussed this in depth.  This is not the issue.  Issue is PKI.  IETF should help with PKI.   This is also in many tutorials for admins being trained on IPv6 now.

thanks
/jim 

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola
> Sent: Monday, March 15, 2004 1:36 PM
> To: v6ops@ops.ietf.org
> Subject: Approaches to use IPsec to secure v6-over-v4 tunnels
> 
> 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
> 
> 
> 
> 
> 
>