below... Yaron Sheffer escribió:
Hi Marcelo, see my responses inline. Thanks, Yaron marcelo bagnulo wrote:Yes this is correct. A NAT box cannot do anything useful to either IKE or IPsec unless it has access to the encryption keys, which would not make sense in our case.Hi Yaron, thank you for your input, see some questions below... Yaron Sheffer escribió:I think we are bundling several different cases together. I will try to enumerate the use cases, to clarify the situation a bit:So, in you opinion, if we have a v6 host communicating with a v4 host a NAT64 in the middle, then they cannot communicate using IPSec, neither transport nor tunnel mode directly between them. That includes doing nor ESP nor AH nor IKE, is that correct?Case 1: v6-only host to v4-only host. I don't think any IPsec solution can be crafted here.
just to make sure that i understand thisDuring the last meeting, people suggested that NAT64 should provide the same level of IPSec support then regular v4NATs That make sense to me, since in general, we can think that a v4 NAT would be as incompatible with IPSec as NAT64
AFAIU, regular NAT support for IPSec is defined in rfc3948However, in RFC3948, there is support for IPSec in NATs both in transport mode and tunnel mode. Tunnel mode seems differnet in the NATv4 case and the NAT64 case, so i understnad that it cannot work However, do you think that the transport mode IPSec as described in rfc3948 cannot work in NAT64?
but this doesn't involves the NAT64 box at all, i guess. So, even if this is a usefull case, this is transparent to the NAT64 box imhoCase 2: one IPsec gateway (a common remote-access deployment).v6-only host ==== (v6-only connectivity) === (optional v4 network) ==== IPsec Gateway ======== v4-only hostWe can use normal IPv6 IPsec in tunnel mode between the v6 host and the gateway, followed by NAT64 on the v4 side.Yes, it should "just work".I'm not sure. The left-hand side NAT64 box (between the v6 network and the v4 network) would need to convert IPv6 IPsec traffic, which is not specifically UDP or TCP into IPv4 traffic. This is not required in the problem statement, AFAICT.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.Ok, so in this case we would have two NAT64 boxes, right?One for inner header and other for the outer header, but the thing is that the inner header is performed AFTER the IPSec validation has been preformed. This may be interesting indeed. Still i think this is transparent to the NAT64 box right?
right good point!i think it makes sense to support this case, i will try to write something about this then
No (sorry I wasn't clear). You can have the box either to the left of the left-hand GW, or to the right of the right-hand GW. As for the hosts in case #1, you cannot have a v4-only GW talk to a v6-only GW.Case 3: two IPsec gateways (site-to-site VPN):v6-only host ==== IPsec GW ==== (v6 and/or v4 connectivity) ==== IPsec GW ====== v4-only hostHere 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.so here we could have a NAT64 box between the two IPSec GW?I mean is it possible that the IPSec GW are one v6 only and the other one IPv4 only?
right
right, but my point is that you actually need to provision this addres, so there doesn't seem to be many advatages w.r.t. to a dual stack case (maybe with some tunnelling technique)Actually we commonly provision such addresses to IPv4 clients today, *inside* the IPsec tunnel. They are known as "Tunnel Inner Address (TIA)".Case 4: dual stack host with v6-only connectivity. Yes this is perverse, but it may actually be common for a while.right, but this not only requires v4 stack in the v6only node (which would be ok, since as you say it seems this will be a common case for a while) but it also requires to provision a valid IPv4 address to the v6 only node and that address is not purely local, since it will be the v4 address the v4 only node has in its IPSec SA, right?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.So, even i agree this is possible i am not sure this is so interesting
But I think I got this case wrong: you end up with a v4 packet, which you want to send to a v4 host, through a v6-only network. It sounds more like tunneling than NAT.
right thanks, marcelo
Thanks, marceloThanks, 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 changedBut 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 imhoSo, the application scenario for NAT64 seems to imply that we cannot assume IPv4 address available in the ipv6 only hostIn summary, i still think that IPSec tunnel case cannot be supported in NAT64 scenarioIt 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, marceloGT> 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 scenarioNote that IPsec transport mode is rarely used in practice.Scanned by Check Point Total Security Gateway.Scanned by Check Point Total Security Gateway.