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

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Mar 2004 20:36:04 +0200 (EET)

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

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 18 Mar 2004 06:21:31 -0500

> > 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.
 > 
 > Could you clarify what you mean with "We" here? :)  Even if you are
 > bright enough to figure it on your own, that doesn't mean everyone
 > else is -- there seems to be ample evidence to the contrary :).  So,
 > at least an Internet-Draft would be useful, to identify the issues
 > concerned.  Whether an Informational RFC would be useful or not would
 > remain to be seen.

=> I'm trying to understand whether the non-trivial part
is implementation-related or interoperation-related. In the
implementation space there are certainly issues like whether
the IPsec HW has been upgraded to handle this without doing 
IPv6 in IPv4 in IPv4 (i.e. IPv4 tunnel mode for a tunnelled
IPv6 packet). But when it comes to interoperability I'm not
sure if there is an issue. I thought that this would work
out of the box. 

Hesham

 > 
 > I also brought this up in the security area, and they certainly 
 > thought this is interesting -- and non-trivial.
 > 
 > --

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 18 Mar 2004 08:35:46 -0500

those working with enterprises to deploy IPv6 currently vendors,
consulting firms, the enterprises, et al.
/jim 

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Thursday, March 18, 2004 4:57 AM
> To: Bound, Jim
> Cc: [email-masked]
> Subject: RE: Approaches to use IPsec to secure v6-over-v4 tunnels
> 
> On Thu, 18 Mar 2004, Bound, Jim wrote:
> > 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.
> 
> Could you clarify what you mean with "We" here? :)  Even if 
> you are bright enough to figure it on your own, that doesn't 
> mean everyone else is -- there seems to be ample evidence to 
> the contrary :).  So, at least an Internet-Draft would be 
> useful, to identify the issues concerned.  Whether an 
> Informational RFC would be useful or not would remain to be seen.
> 
> I also brought this up in the security area, and they 
> certainly thought this is interesting -- and non-trivial.
> 
> --