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