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

[Paul Wouters]

FYI, this bug is now fixed.

Paul

---------- Forwarded message ----------
Date: Fri, 17 Feb 2012 11:43:58
From: Paul Wouters <pwouters at redhat.com>
To: ipsec at ietf.org
Subject: Re: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem
X-Spam-Flag: NO

On 02/16/2012 09:49 AM, Yoav Nir wrote:
>
> On Feb 16, 2012, at 4:43 PM, Paul Wouters wrote:
>
>> On Thu, 16 Feb 2012, Yoav Nir wrote:
>>
>>>> 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).
>>>
>>> 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.
>>
>> 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.
>
> 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?

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