Subject: A slightly more detailed analysis Re: NAT64 and IPsec support

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 1 Apr 2008 10:46:51 +0100

Marcelo et.al.,

So, I looked into this in a bit more detail. Admittedly I am not a
security expert but I do not think you have to be one to figure this
out at least to some level.

- First in terms of unmodified end nodes:

RFC2765 (SIIT) claims that ESP Transport mode can work over it. This
appears to be true given the fact that ESP Transport mode as defined
in RFC4303 only covers the headers following the ESP header; see
diagrams in pages 18/19 of RFC4303.

Note, however, that while ESP Transport mode does not cover IP
headers, it does cover Transport and higher headers, so it is NOT
possible to perform port translation or to do an ALG processing. So
SIIT assumes that NO port translation is going on and each IPv6 only
node is using all the ports of each IPv4 address available to the SIIT
box. This requires as a minimum, one IPv4 address for each IPv6 end
node in a concurrent communication session, and it is the reason why
NAT-PT had to also exist.

I think this conclusively renders "IPSEC over NAT64 for unmodified end
nodes" unrealistic. Any disagrees with that?

- Now about modified end nodes:

As we discussed before RFC3948 works based on UDP encapsulation which
has become the default v4NAT traversal technique. The premise for this
type of solution is that by encapsulating the traffic we can limit the
effects of translation to the encapsulation header, leaving the inner
header untouched. I think this is not sufficient when IPv6-only nodes
interact with IPv4-only nodes since no matter what encapsulation we do
in the end there is no way for the two peers to form IP headers of the
same version and use them as untouched inner headers.

This seems like a dead-end but there is an avenue some people seem to
want to explore. This would require one of the peers (presumably the
IPv6-only side) to be able to put together an IPv4 header and apply
ESP style encapsulation, even if it does not run a full IPv4 stack.
In this case, at least in theory, the two peers can then form a
session based on the same version of IP. I think then there are two
possibilities to explore:

1) An IPv6 tunnel is created between the IPv6-only end node and the
NAT64 box. The IPv4 session is then encapsulated over it and it is
protected by IPSEC as required. This means that the IPv6 end node
knows the external IPv4 address of NAT64 box and the port number to
use.

2) A UDP/IP tunnel is created end to end ala RFC3968. Of course this
means that the IPv6-only node does UDP/IPv6, which is then translated
to UDP/IPv4 by NAT64. The IPv4 session is then encapsulated over it
and it is protected by IPSEC as required. This means that the source
IPv4 address and port numbers used by the IPv6-only node in the inner
headers will have to be valid and non-overlapping at the IPv4-only
side too.

In both of the above cases IKEv2 will still have to be looked at and
see if there is any hope of making that work over NAT64. Making this
work for incoming communication is of course even harder. In general,
both options present serious challenges which if they are overcome
something resembling end to end IPSEC could in theory emerge.

My personal opinion, for whatever it is worth, is that this is not a
good road to go down, but maybe defining something like this in more
detail to see how awful it really is, is still useful. We can always
discard it later.

Maybe there are also other alternatives I am missing here in which
case it would be nice to hear about them.

Regards
George

On Fri, Mar 28, 2008 at 8:14 PM, marcelo bagnulo <[email-masked]> wrote:
> Hi,
>
>  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.
>
>  However, i am not so clear about the tunnel mode.
>  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, but this again will be different
>  than the IPv4 NAT case, since the inner header in the IPv4 NAT case
>  remains unchanged, while we would be changing it in this case. So i am
>  finding that the tunnel mode wouldn't be so directly supported using the
>  IPv4 NAT traversal techniques for IPSec.
>
>  However, i am not an expert on this, so i may get this completelly
>  wrong. any guidance on this would be appreciated
>
>  Regards, marcelo
>
>
>

---

From: marcelo bagnulo <[email-masked]>
Date: Tue, 01 Apr 2008 15:41:58 +0200

Hi Goerge,

thanks for the summary, i was planning to do a similar effort myself, 
but since you have done that already :-)

> nodes" unrealistic. Any disagrees with that?
This is my conclusion as well.
IPSEc wihtout at least one of the endpoints involved is not possible 
(note that this is similar to the IPv4NAT, since in IPv4NAt IPSec 
support endhosts need to be updated as per RFC3948)

So i am planning to NOT to include a basic requirement  abou any form of 
IPSec support wihtout endpoint support, ok?
> case it would be nice to hear about them.
I understnad that what you describe above is only for IPsec tunnel mode. 
there is also transport mode with modified hosts, which i think it would 
be easier to make it work, don't you think?

My conclusion of this discussion w.r.t. the requirements is that it 
would be possible to make it work, but this would require modifications 
of the endpoints, so, i am thinking in a requirement like:

IPSec MUST be supported but modifications to the endpoints may be needed.

Now, i have a few related questions:
- do we need to upgrade btoh endpoints or would it be enough if we just 
upgrade one? ( I mean, this could change the requieremtn meaning that 
the solution must support IPSec if only the v6 node is upgraded with 
special IPSec handling mechanisms)
- Is there anything that the NAT64 needs to do in order to make ths 
support easier? I mean, at least at this point, it seems possible that 
IPsec traffic will flow through the NAT64 box, so at least is should be 
possible to do somehting with that traffic. for instace, how does the 
NAT64 box handles that traffi when NAPT is being performed? Are there 
any other thing s that the nat64 could do to make life of the endpoints 
supporting IPSec clearly easier?

Regards, marcelo

---

From: marcelo bagnulo <[email-masked]>
Date: Tue, 01 Apr 2008 17:39:39 +0200

George Tsirtsis escribió:
> inline...towards the end...
>
> On Tue, Apr 1, 2008 at 2:41 PM, marcelo bagnulo <[email-masked]> wrote:
>   
>> Hi Goerge,
>>
> GT> No, Marcelo, what I describe above applies to BOTH!. Remember that
> when you do UDP/IP based NAT traversal, IPSEC applies to whatever you
> send OVER the unprotected UDP/IP tunnel. So, on top of UDP/IP you can
> run either  transport or tunnel mode IPSEC. Both have problems IMO.
>
>   
right, i was confused about this, i agree with you

> GT> I think Brian noted correctly that changes to IPv4 nodes are
> unacceptable, so we can only change IPv6 nodes
>
>   
Well, i agree with that for the basic communication case, but for IPSec 
i think it is different. I mean, i think that the NAT64 mechanism MUST 
provide support for basic communications wihtout requiring changes in 
hosts (niether v6 nor v4, but we are only requiring no changes to the v4 
hosts at this point)

However, for supporting more advanced protocols, like IPSec, DNSSEc, 
referrals and so on, it would be possible to require changes in v4 hosts 
too.
I mean, today if you want to support incoming communications in v4 
behind a nat you need support in the v4 node to open a hole and that is ok.

So, the requirements are split in two:
BAsic requirements that need to be fulfilled wihtout mdofications on v4 
hosts
Advanced requirements that need to be fulfilled, but may require v4 host 
changes. Within those i would include DNSSec, IPSec, referrals and maybe 
others. Of course, if we can make this work changing only the v6 side, 
much better and we can require that.

So my question is: is is possible to support IPSec with only modifying 
the v6 side and keeping the v4 side untouched? from you description 
above it seems to me that it would be possible (i guess that the v4 side 
needs to implement rfc3948, right?)

> GT> In option 1 in my e-mail I suggest that an IPv6 tunnel between the
> IPv6 end node and the NAT64 box can be established. Then fake IPv4 can
> run on top of it.
>
>   
right, so the NAT64 box would need to do some special processing for 
this, i guess

> GT> I think you need to articulate why and in what way Transport mode
> IPSEC is easier. My analysis above,  indicates that it is NOT so easy.
>   
i see your point now and i agree

regards, marcelo

> It seems that you will have to do your own analysis after all to
> figure this out since you are not taking my word for it :-)
>
> George
>
>
>   
>>  Regards, marcelo
>>
>>
>>
>>  > Regards
>>  > George
>>  >
>>  >

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 01 Apr 2008 19:01:22 +0300

Hi Marcelo, George,

I agree with Marcelo that v4 hosts should not be modified.

George's 1st possibility looks too much like STUN for my taste :-) so I 
would not adopt it.

But the second possibility is *almost* workable. In Tunnel Mode, the 
tunnel-internal v4 address can be received from the v4 peer (easy if the 
peer happens to be a gateway). As to the external v4 address (the only 
address when using Transport Mode), I don't see how you can get one on a 
v6-only network. Note that a random address would do just fine here, we 
have to deal today with the whole world using 192.168.0.1. And IKEv2 may 
actually not require any changes.

Thanks,

    Yaron

marcelo bagnulo wrote:

> So i am planning to NOT to include a basic requirement  abou any form 
> of IPSec support wihtout endpoint support, ok?
> I understnad that what you describe above is only for IPsec tunnel 
> mode. there is also transport mode with modified hosts, which i think 
> it would be easier to make it work, don't you think?
>
> would be possible to make it work, but this would require 
> modifications of the endpoints, so, i am thinking in a requirement like:
>
> - do we need to upgrade btoh endpoints or would it be enough if we 
> just upgrade one? ( I mean, this could change the requieremtn meaning 
> that the solution must support IPSec if only the v6 node is upgraded 
> with special IPSec handling mechanisms)
> IPsec traffic will flow through the NAT64 box, so at least is should 
> be possible to do somehting with that traffic. for instace, how does 
> the NAT64 box handles that traffi when NAPT is being performed? Are 
> there any other thing s that the nat64 could do to make life of the 
> endpoints supporting IPSec clearly easier?
>
> Regards, marcelo
>
>> Regards
>> George
>>
>>
> Scanned by Check Point Total Security Gateway.
>