Re: NAT64 and IPsec support

["George Tsirtsis" <tsirtsis@googlemail.com>]

Iljitsch/Marcelo,

I am a bit confused by this discussion. See below.

On Fri, Mar 28, 2008 at 8:10 PM, Iljitsch van Beijnum
<iljitsch@muada.com> wrote:
> On 28 mrt 2008, at 20:14, marcelo bagnulo wrote:
>
>  > Another issue that was brought up during the meeting was IPSec
>  > support.
>  > I have been reading RFC3948 and i have some questions.
>  > I understand that if transport mode can work through v4 NATs using
>  > RFC3948 UDP encapsulation and soem other tweaks defined in the RFC,
>  > then it is reasonable to expect that the same level of support of
>  > support can be achieved in NAT64.
>  > so we could simply add a requirement that NAT64 mechanisms should
>  > support the use cases supported by RFC3948.
>
>  Ok, this is all easy enough (and should equally apply to both tunnel
>  and transport mode), except that RFC 3948 doesn't really mention IKE,
>  which I think needs to be changed to support NAT64 or NAT46. Question
>  to the IPsec experts: would it be possible to have the updated IKE
>  implementation on just one end (presumably the v6 end) where the other
>  end thinks it just sees regular NAT44?
>
>
>  > In tunnel mode, we have two IP headers and the NAT64 will only
>  > translate one of them (by default, if we don't do anything special
>  > with it).
>  > so, the problem, is that even if the outside IP  header is
>  > translated with the NAT64 box, the inner header remains in the
>  > original IP version, so i am wondering if this doesn't present
>  > additionla difficulties. The option is to translate both headers
>
>  The inner header is encrypted and/or protected by a HMAC so
>  translating it is not possible. However: there are two possibilities:
>
>  1. The inner header is IPv6. In that case, it seems reasonable that
>  IPv6 could also be used for the outer header so the issue is moot
>

GT> Yes, this works only if the stab network and/or the NAT64 box has
an IPv6 way of reaching the destination, which is fine.

>  2. The inner header is IPv4. In that case, no translation is required
>  so the issue is also moot
>

GT> But then the NAT64 box is irrelevant.
The only thing we have to make sure for both of these cases is that
NAT64 does not interfere with native IPv4 and native IPv6 traffic.

GT> The only question in my mind that is relevant to the NAT64
discussions, is whether IKE/IPSEC, can work between an IPv6only node
and an IPv4only node. IMHO there is something perverse about expecting
such a thing to work and I would just forget about it.

GT> Note that in IPv4NAT, one can tunnel over it, meaning that NATv4
is applied only on the (non-secured) tunnel header and the inner
header can be IPSECed with no problems. When the two peers do not
speak the same IP version, however, such an approach does not help
i.e., all IP-layer headers will require translation which will always
break IPSEC

GT> So, unless we are talking about IKE/IPSEC that somehow does NOT
cover IP-layer headers, I do not think any solution to this exists.
But maybe I am missing something?

Regards
George