tech-net archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: UDP_ENCAP_ESPINUDP_NON_IKE

On 5/21/2018 1:07 PM, Maxime Villard wrote:

Le 21/05/2018 à 17:47, Chuck Zmudzinski a écrit :
We would have to configure a remote host that uses the non-IKE markers and 
doesn't use the RFC to test the way the kernel currently deals with that
case.
Yes, and that's a case that we are not supposed to support. Just like we're not supposed to support all the drafts that led to the many RFCs available 
out there.
So I suggest we disable ENABLE_NATT_00. This will disable draft-00, in such a way that racoon will never use non-IKE markers. Then we remove ESPINUDP_NON_IKE 
from the kernel.
If we do this, we will find out if the old code was working and someone was relying on it, because this will break it and that person will file a bug 
report!


What? The kernel code doesn't work in the first place.
Disabling NATT_00 on racoon under NetBSD does not remove a feature, since it 
already doesn't work on NetBSD.

To me the current code in racoon is wrong, it shouldn't automatically use
non-IKE markers when there is no NAT-T.


Yest, that is definitely a bug in the current code in racoon.




And no, there won't be a bug report, for the same reason we didn't get a
report in the last 13 years about broken non-IKE markers in the kernel.


I agree.
(Well, there was one guy that figured this out a few months ago, and it was 
you.)
I actually have been working on this for several years and I forget exactly what prompted me to post about this problem to the mailing lists a few months ago, but I am pleased that we are getting this fixed in NetBSD!
Can you recompile racoon without ENABLE_NATT_00 and test again? You should be able to do so by uncommenting the #define in /src/lib/libipsec/config.h. 

note: I meant _commenting_, as you probably understood.



Maxime
It looks to me like that will work. I will try it when I get a chance. I can most quickly test it on NetBSD 7.x because that is the version I am using in 
my environment, and if that works as expected I will also test it with
NetBSD 8 and current and let you know what I find.


Thanks,
Maxime
This worked exactly as expected on netbsd-7. I did not test a full build, but it compiled and ran exactly as expected when I rebuilt in /src/lib/libipsec and in /src/usr.sbin/racoon on netbsd-7 after commenting out the #define of ENABLE_NATT_00 in /src/lib/libipsec/config.h and installing the new racoon and libipsec.so.3.0 in my netbsd-7 system that is modified with a kernel that patched the UDP_ENCAP_ESPINUDP_NON_IKE code to deal with my misconfigured racoon configuration. 

Results as reported by the racoon log:

Before patching racoon:
May 20 21:06:12 ave racoon: INFO: respond new phase 1 negotiation: 192.168.xxx.xxx[500]<=>xxx.xxx.xxx.xxx[500] 
May 20 21:06:12 ave racoon: INFO: begin Identity Protection mode.
May 20 21:06:12 ave racoon: INFO: received Vendor ID: RFC 3947
May 20 21:06:12 ave racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02 May 20 21:06:12 ave racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02 May 20 21:06:12 ave racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00 
May 20 21:06:12 ave racoon: INFO: received Vendor ID: DPD
May 20 21:06:12 ave racoon: [xxx.xxx.xxx.xxx] INFO: Selected NAT-T version: RFC 3947
After patching racoon by commenting out the #define of ENABLE_NATT_00 in /src/lib/libipsec/config.h:
May 20 22:10:08 ave racoon: INFO: respond new phase 1 negotiation: 192.168.xxx.xxx[500]<=>xxx.xxx.xxx.xxx[500] 
May 20 22:10:08 ave racoon: INFO: begin Identity Protection mode.
May 20 22:10:08 ave racoon: INFO: received broken Microsoft ID: MS NT5 ISAKMPOAKLEY 
May 20 22:10:08 ave racoon: INFO: received Vendor ID: RFC 3947
May 20 22:10:08 ave racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02 
May 20 22:10:08 ave racoon: INFO: received Vendor ID: FRAGMENTATION
May 20 22:10:08 ave racoon: [xxx.xxx.xxx.xxx] INFO: Selected NAT-T version: RFC 3947
Vendor ID draft-ietf-ipsec-nat-t-ike-00 is no longer received from the remote host, as expected.
I also edited my kernel to report if it is using the UDP_ENCAP_ESPINUDP_NON_IKE branch or the UDP_ENCAP_ESPINUDP branch in udp_usrreq.c. As expected, now I get this in /var/log/messages: 

May 20 21:13:53 ave /netbsd: udp4_espinudp: UDP_ENCAP_ESPINUDP is set.
It is working correctly now because racoon is not incorrectly telling the kernel it is using NON_IKE markers.
Things get a little more complicated for the case with the patched racoon and racoon.conf configured incorrectly. To remind you, the incorrect configuration was that I had the wrong statement in the listen directive of racoon.conf for port 4500. I used isakmp instead of isakmp_natt in the listen directive.
As I predicted, it does not work in this case, because in this case, racoon is configured to not do any version of ESP in UDP, so after phase 1 and phase 2 are negotiated successfully and the ESPINUDP packets start coming from the remote host, the kernel tries to do normal UDP processing on them instead of decapsulating them and sending them for processing by ipsec. The racoon log indicates the kernel sends the ESP in UDP back to racoon which complains about packets being too big and after a while the connection attempt fails and the remote host eventually terminates the connection with an error.
Is this a bug? Well, on one hand, we should not support a misconfigured setup, so it is correct for the connection to fail. On the other hand, I would argue that it is still a bug in racoon to try to negotiate a connection based on RFC 3947 and 3948 and actually let the connection get to the point where the remote host is sending us ESP in UDP packets that we cannot handle correctly. In this case, I think the correct behavior is for racoon to detect that it is not configured correctly to support RFC 3947 and 3948 at startup and at least log a warning or even exit with an error and report that racoon is not configured correctly to handle NAT-T connections using RFC 3947 and 3948. I am working on a patch to racoon to do that. Even this patched racoon does not provide much useful information in its log messages to assist in the debugging process. This is why no one has solved this problem for the last 13 years.
Thank you for all your help. I am glad to help get support for this feature in NetBSD. 

Chuck
Home | Main Index | Thread Index | Old Index