Subject: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Feb 2012 15:23:50 -0500

Hi,

There are many IPsec related standards, and I was hoping to use the 
combined experience of the list to tell me if in fact, these new apple 
devices have a bug, or whether it is an RFC or draft anywhere.

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.

On the server, this is a problem. We now need to build tunnels to a 
random publicly addressable IP. Since that is dangerous and could be 
hijacking a real IP address, openwan only limits per default to RFC1918 
space (and 25/8 since too many North American telco's use this and the 
UK MoD seems to not care). As a result, to make this work, we need to 
allow basically any public IP to be tunnelled.

Is this indeed a bug in these devices? If so, is there anyone from Apple 
here that I can talk to and resolve this. Or if this is a 
feature/draft/rfc, could someone point me to it?

Thanks,

Paul

---

From: Nico Williams <[email-masked]>
Date: Mon, 13 Feb 2012 14:30:37 -0600

You can do one thing on the server side: assign an IP address to the
client and do NAT in the tunnel.

This approach saves you the need to implement address allocation
extensions in KE protocols :)  (IIRC IKEv1 has no standard address
allocation feature.)

Nico
--

---

From: Scott C Moonen <[email-masked]>
Date: Mon, 13 Feb 2012 15:29:56 -0500

Paul, for IKEv2, according to RFC 5996:

"If Network Address Translation Traversal (NAT-T) is supported (that is, if
NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices
MUST be able to receive and process both UDP-encapsulated ESP and
non-UDP-encapsulated ESP packets at any time.  Either side can decide
whether or not to use UDP encapsulation for ESP irrespective of the choice
made by the other side.  However, if a NAT is detected, both devices MUST
use UDP encapsulation for ESP."

I'm not aware of similar statements that you could appeal to for IKEv1, but
in the long run you're going to need to accommodate this behavior anyway,
at least for IKEv2.

Scott Moonen ([email-masked])
Secure Hybrid Cloud and z/OS Communications Server
http://www.linkedin.com/in/smoonen

From:	Paul Wouters <[email-masked]>
To:	[email-masked]
Date:	2012-02-13 15:24
Subject:	[IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem
Sent by:	[email-masked]

Hi,

Thanks,

Paul

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Mon, 13 Feb 2012 22:45:14 +0200

> feature/draft/rfc, could someone point me to it?

Hi Paul

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.

So you have a routable address on the outside, and your own chosen address on the inside. 

So what is the issue?

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Feb 2012 21:33:09 -0500 (EST)

> 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.

> 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. 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)

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)

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 16 Feb 2012 16:11:46 +0200

Paul Wouters writes:
> > 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. 
> 

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. 

> 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). 

> (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-masked]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 16 Feb 2012 16:29:05 +0200

> compatible with the RFC3947 (which (which was published January 2005,

They don't always do that. But looking at their MainMode packet 1 in wireshark, They send the following VIDs:
- RFC 3947 Negotiation of the NAT-Traversal in the IKE
- draft-ietf-ipsec-nat-t-ike
- draft-ietf-ipsec-nat-t-ike-08
- draft-ietf-ipsec-nat-t-ike-07
- draft-ietf-ipsec-nat-t-ike-06
- draft-ietf-ipsec-nat-t-ike-05
- draft-ietf-ipsec-nat-t-ike-04
- draft-ietf-ipsec-nat-t-ike-03
- draft-ietf-ipsec-nat-t-ike-02
- draft-ietf-ipsec-nat-t-ike-02\n
- RFC 3706 DPD (Dead Peer Detection)

I guess what they later do depends on what VID they get in the reply. There were quite a few versions of Windows server that returned 90cb80…427b1f (draft-ietf-ipsec-nat-t-ike-02\n), so maybe Paul's implementation was a surprise for iOS.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Feb 2012 09:43:17 -0500 (EST)

> I guess what they later do depends on what VID they get in the reply. There were quite a few versions of Windows server that returned 90cb80…427b1f (draft-ietf-ipsec-nat-t-ike-02\n), so maybe Paul'…

I'll make sure this is not an implementation issue on our side.

Did any large deployment switch to removing all the draft VIDs? If so,
how many problems did that cause? I'd be happy to remove the ancient
drat cruft, especially if it increases interoperability.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Thu, 16 Feb 2012 16:49:32 +0200

> drat cruft, especially if it increases interoperability.

Our implementation supports the RFC and "draft-02\n", which is what Microsoft clients added in some service pack of XP.  We reply according to the last recognized NAT-T VID, which in this case is the draft-02\n one. 

When we do this, we don't get any weird encapsulation modes like you do.  Do you reply with the RFC one?

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Fri, 17 Feb 2012 11:43:58 -0500

> When we do this, we don't get any weird encapsulation modes like you do.  Do you reply with the RFC one?

It turns out we had a special check on OSX and did some workaround for a
bug that AFAIK is no longer there (involving sending a 0.0.0.0 NAT-OA),
and fell back to a draft instead of rfc version. I also removed sending
some of the draft vendorids. This together seems to have resolved the
problem, and OSX/iOS can now properly connect from public as well as
through NAT-T.

Thanks for all the feedback from everyone!

Paul