Paul Wouters writes: > On Mon, 13 Feb 2012, Yoav Nir wrote: > > >> When using L2TP/IPsec mode with IKEv1, the latest iphones/OSX machines, > >> when on public IP, and when no NAT is detected, send UDP_ENCAP packets > >> where the inner IP is the same as the outer IP. > > > I'm not sure I follow you. L2TP/IPSec uses transport mode ESP, so > > the inner IP is inside the L2TP tunnel. That address is assigned > > in the IPCP protocol by your gateway. > > I'm sorry, inner IP and outer IP were a bad choice of words. > > The devices send an Encapsulation Mode attribute 61443 (private use, but > generally known as ENCAPSULATION_MODE_UDP_TUNNEL_DRAFTS) and starts > using this ESPinUDP where the UDP header has the same public IP as the > encapsulated ESP packet. Normally, clients use their pre-NATed IP > address for that.
Are you really telling me they are using a private numbers from the internet draft that expired more than 10 years ago, and which is not compatible with the RFC3947 (which (which was published January 2005, i.e. 7 years ago). Also note that those private numbers were only present up until draft-ietf-ipsec-nat-t-ike version 04 and they were removed at the 05 version as the NAT-T protocol changed in the incompatible way, i.e the NAT-T protocol used when using those private numbers is different than what is defined in the RFC3947. Does what you said above mean, that they do not support RFC3947 at all? Or it is just that they send multiple vendor IDs for NAT-T and other end happened to select some vendor id based on some draft, not the RFC version? If it is the latter, just make sure your implementations prefer the RFC version instead of the draft version (or think about removing the draft versions completely, they are not really supposed to be out there anymore). In the later RFCs (i.e. IKEv2 NAT-T) it was explicitly mentioned that both ends can enable NAT-T even when no nat is found, so that kind of usage is completly legal for those setups. The RFC3947 says that if there is no NAT between (i.e. inner and outer IP are same) then: If there is no NAT box between, there is no point in wasting bandwidth by adding UDP encapsulation of packets. Thus, UDP- Encapsulation SHOULD NOT be used. I.e. it is SHOULD NOT, which means you still might need to support receiving UPD encapsulated ESP packets even when you do not have NAT between. > > So what is the issue? > > In roadwarrior connections, imagine I setup my LAN to be > 193.110.157.0/24. My public IP is 1.2.3.4. I now setup a connection > using ESPinUDP where I negotiate 193.110.157.101/32 as my address on > the ESP packet encapsulated in the UDP packet that has 1.2.3.4. Now > I will get all the traffic of www.openswan.org (193.110.157.101) that > the remote gateway meant to send to www.openswan.org. For this reason, > we try to limit the addresses that can be used to RFC1918 addresses. This kind of limitations are not part of the IPsec. They can be part of the default policy, but must be specified in the policy. I.e. if the policy says other end can only has inner IP address of 10.0.0.0/8 then that limits what other end can do. If there is no such policy then everything is allowed. > The OSX bug is causing us to have to allow any public IP address for > no good reason, as it should not be using ESPinUDP to begin with > when it is on an unfiltered public IP. (though the mention that > IKEv2 tells us we need to accept this anyway is unfortunate, so we > will have to deal with this anyway) I am not sure it is bug in OSX, as there might be completely valid reasons why they decide to go against that SHOULD in the RFC3947. On the other hand if they used the some old internet draft version of the NAT-T, I do not have any idea whether that allowed it or not (and I am not interested to read 10 year old drafts just to find out what those now expired drafts said the now obsoleted protocol might want to do). > The best openswan can do now, is to allow 0/0 with the exception of its > own network and the network it assigns via L2TP. And have another layer > of packet inspection to avoid sending traffic to the wrong destinations. > (like SAref tracking, or Labeled IPsec) How does this differ from using normal tunnel mode ESP? If the other end creates SA which selectors overlap some public addresses, you need to do exactly same checks. On the other hand it does not really matter if you forward all openswan.org traffic to the tunnel unless you happen to be router processing openswan.org traffic. In normal case the openswan.org traffic does not come to your SGW at all. Normally allowing other end to claim to be any IP-address is considered bad for anyways, but restricting them to only steal private address does not help. So even if you have setup which says the addresses inside the tunnel must be from RFC1918 address spaces, that would still allow client to steal traffic intended for some other client, or to your local network. I think I must be missing something in your scenario. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
