Hi There is something that I think is missing from all three proposals, and that is the handling of duplicate protected networks. As long as we live in a predominantly IPv4 world, we have a lot of NATs and a lot of RFC 1918 addresses.
So unprotected traffic from such networks gets NATted by the perimeter gateway (or a dedicated device between the gateway and the Internet). For protected traffic, there qre two options: 1. Translate the traffic before sending it through the tunnel, or 2. Send packets from non-routable addresses through the tunnel Option #1 has a weird side effect. If the translated address is a routable address of the gateway, the peer gateway cannot forward it to the Internet without translating it again: the return packets would go directly to the original gateway, creating some asymmetric routing. So let's assume option #2, the other tunnel endpoint will NAT the traffic behind itself if it forwards the traffic to the Internet. If it forwards the traffic through another tunnel, it has the same choices as the first gateway. But if it forwards the traffic to its own protected domain, it has two options 1. Forward them as is. That requires that there be no duplicates, and that routing will be set up so that return packets go to this gateway., or 2. NAT the packets behind itself. There are more subtleties to this, but it's a complexity that network people deal with all the time. The NATs are configured where appropriate, and collisions are avoided through a combination of NATs and a manual partitioning of the RFC 1918 space. All this goes out the window the moment you try to connect with other administrative domains or worse - merge some administrative domains. And a dynamic setup of tunnels runs a high risk of having the same network on both sides of the tunnel. Consider the trivial example. Host a, behind gateway A, sends traffic to host c behind gateway C, but the traffic goes through gateway B, which is the hub gateway. c is a server, so it has port forwarding on gateway C, and C belongs to another organization. A is the gateway of a branch office. Every branch office has a different 192.168.x.0/24 subnet, so within the administrative domain, all hosts have unique IPs. So A sends the ac packet unmodified. B is an egress gateway, so it NATs all such addresses behind itself. That's OK because a is a client. Now, regardless of which solution we choose, it is decided that A should send traffic directly to C, skipping B. But that means that A should now NAT the packets, because C does not wish to receive non-routable IP addresses from a partner. It has its own 192.168.x.x addresses within its network. But here's a problem. Regardless of whether A does or does not NAT when sending traffic to C, connections are going to be severed. Why? Because the source IP address of the traffic coming from 'a' changes. Before 'c' got the traffic from B's public address. But now it's coming either from 'a''s non-routable address, or from A's public address. Either way, TCP connections get severed. I don't think this issue is addressed in any of the current drafts. Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
