Re: NAT64 and IPsec support

[Yaron Sheffer <yaronf@checkpoint.com>]

I think we are bundling several different cases together. I will try to 
enumerate the use cases, to clarify the situation a bit:

Case 1: v6-only host to v4-only host.

I don't think any IPsec solution can be crafted here.

Case 2: one IPsec gateway (a common remote-access deployment).

v6-only host ==== (v6-only connectivity) === (optional v4 network) ==== 
IPsec Gateway ======== v4-only host

We can use normal IPv6 IPsec in tunnel mode between the v6 host and the 
gateway, followed by NAT64 on the v4 side.

I'm not sure what the gateway will do if we also have NAT64 on the 
left-hand side and IPsec traffic is then encapsulated in UDP/IPv4. We 
might need to require IPsec peers to allow this situation. Note that in 
this sub-case, the encrypted traffic is never touched, only the UDP 
encapsulation is.

Case 3: two IPsec gateways (site-to-site VPN):

v6-only host ==== IPsec GW ==== (v6 and/or v4 connectivity) ==== IPsec 
GW ====== v4-only host

Here you can do NAT64 either on the v6 or the v4 side, assuming both are 
mixed networks, and we'd better recommend which one we prefer. IPsec 
here is definitely tunnel mode.

Case 4: dual stack host with v6-only connectivity. Yes this is perverse, 
but it may actually be common for a while.

In this case you could envision NAT64 happening on the host (!) which 
creates an IPv4-IPsec tunnel with its peer, encapsulates it in UDP and 
sends it into the IPv6 network.

Thanks,
   Yaron

marcelo bagnulo wrote:

> Iljitsch van Beijnum escribió:
> > On 29 mrt 2008, at 11:25, marcelo bagnulo wrote:
> >
> > > So IPSec tunnel mode, even if it is supported in v4NATs seems hard 
> > > to support in NAT64, since each of the peers only speack one 
> > > IPversion and the inner IP header cannot be changed
> >
> > But wouldn't most hosts, even if they only have IPv6 connectivity, 
> > usually also support IPv4 in their stack during the transition 
> > period? I can imagine that constrained devices may want to drop IPv4 
> > support but it's hard to imagine devices that are willing to run 
> > IPsec but are too constrained to support IPv4.
>
> i may agree with the point that v6 only hosts will have an IPv4 stack, 
> but in order to make it work, we not only need to have the v4 stack 
> but also the v4 address, which needs to be present in the IPSec SA in 
> the IPv4 only hosys (i.e. it is an IPv4 address that will be known by 
> the peer)
>
> So, if we assume that this is possible, then we are in the dual stack 
> scenario, then we simply need a tunnel between a dual stack host and 
> an IPv4 only host, which is not the application scenario for NAT64 imho
>
> So, the application scenario for NAT64 seems to imply that we cannot 
> assume IPv4 address available in the ipv6 only host
>
> In summary, i still think that IPSec tunnel case cannot be supported 
> in NAT64 scenario
>
>
> > It starts to look to me that the IPv6 side in a NAT64 scenario could 
> > possibly do everything that's needed to make IPsec work through NAT64 
> > the same way it today works through NAT44, with only minimal 
> > cooperation from the NAT box.
> i still cannot agree with that
> regards, marcelo
>
> > > > GT> So, unless we are talking about IKE/IPSEC that somehow does NOT
> > > > cover IP-layer headers,
> >
> > > yes, there seems to be one of such cases, which is IPSec transport 
> > > mode the so called telecommuter scenario
> >
> > Note that IPsec transport mode is rarely used in practice.
>
>
>
> Scanned by Check Point Total Security Gateway.