[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 1 apr 2008, at 17:39, marcelo bagnulo wrote:
> I think this conclusively renders "IPSEC over NAT64 for unmodified end 
> nodes" unrealistic. Any disagrees with that?


Right.
So i am planning to NOT to include a basic requirement abou any form of 
IPSec support wihtout endpoint support, ok?
I agree with that. We can encourage translator builders to look at RFCs 3947 and 3948 (IKE and ESP through NAT, respectively) so they can be sure they don't break those, but apart from that it looks like the translator isn't in the position to help or hurt IPsec support.
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
Hm, I think there are several ways to make it work, in addition to countless ways that can't work. Two examples of the former: 

A -- T -- B

A is a host with an IPv6/IPv4 stack but only IPv6 connectivity
T is the translator
B is an IPv4 host
In this case, A pretty much has to act like it has IPv4-behind-NAT and present an RFC 1918 address in IKE towards B, and then subsequently generate segments (transport mode) or packets (tunnel mode) that make sense as IPv4, then put those in ESP, UDP and IPv6 and send them to B through the translator. B doesn't have to know about any of this. 

A -- T --S -- U -- B

A is a host with an IPv6/IPv4 stack but only IPv6 connectivity
T is the translator in the service provider network
S is a dual stack security gateway that terminates IPsec
U is a translator part of B's network
B is an IPv4 host
In this scenario A can negotiate inner IPv6 headers with S but this means both S and A must be updated. The inner packets are then translated again for consumption by B.
IPSec MUST be supported but modifications to the endpoints may be needed. 

No, MUST is too strong.
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?) 

I think so, yes. See above.