[Openswan dev] [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem (fwd)

[Paul Wouters]

---------- Forwarded message ----------
Date: Thu, 16 Feb 2012 09:11:46
From: Tero Kivinen <kivinen at iki.fi>
Cc: "ipsec at ietf.org" <ipsec at ietf.org>, Yoav Nir <ynir at checkpoint.com>
To: Paul Wouters <pwouters at redhat.com>
Subject: Re: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem
X-Spam-Flag: NO

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.
-- 
kivinen at iki.fi
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec