NetBSD Problem Report #44962

From Wolfgang.Stukenbrock@nagler-company.com  Fri May 13 13:01:23 2011
Return-Path: <Wolfgang.Stukenbrock@nagler-company.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 7AB5E63B95D
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 13 May 2011 13:01:23 +0000 (UTC)
Message-Id: <20110513125806.CC69D42F698@s0g7.nagler-company.com>
Date: Fri, 13 May 2011 14:58:06 +0200 (CEST)
From: Wolfgang.Stukenbrock@nagler-company.com
Reply-To: Wolfgang.Stukenbrock@nagler-company.com
To: gnats-bugs@gnats.NetBSD.org
Subject: IPSEC/FAST_IPSEC and racoon does not work reliable with Windows 7 Clients
X-Send-Pr-Version: 3.95

>Number:         44962
>Category:       kern
>Synopsis:       IPSEC/FAST_IPSEC and racoon does not work reliable with Windows 7 Clients
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri May 13 13:05:00 +0000 2011
>Originator:     Dr. Wolfgang Stukenbrock
>Release:        NetBSD 5.1
>Organization:
Dr. Nagler & Company GmbH
>Environment:


System: NetBSD s0g7 5.1 NetBSD 5.1 (NSW-locationGW_2) #2: Mon Mar 7 10:35:06 CET 2011 wgstuken@s012:/export/NetBSD-5.1/N+C-build/.OBJDIR_amd64/export/NetBSD-5.1/src/sys/arch/amd64/compile/NSW-locationGW_2 amd64
Architecture: x86_64
Machine: amd64
>Description:
	There seems to be some problems with the IPSEC implementations and the racoon in NetBSD 5.1.

	Windows does not support IKEv2, it uses ISAKMP for key exchange.

	The affected setup.
	I'm running a tunnel from a Windows 7 client to a NetBSD server. The windows client assignes an additional
	IP address to it's interface and routing information for some networks to a fictive gateway on the network of
	the additional IP address. (Now any new connection to the routed networks will get the addtional IP address
	as src-address.) The trafic from this address to the routed subnets is redirected into the tunnel by
	some filter rules.
	This setup works fine - even on Windows 7.
	On the NetBSD system a tunnel-SPD is added into the kernel and a preshared key is placed in the racoon password file.
	Setup done. When the client now connects to an IPaddress that is routed through the tunnel ISAKMP is initated
	by the windows client and if it succeeds, the connect succeeds too.
	So far everything is fine.
	After some time the client starts rekeying - and here the problems comes up.
	"Sometimes" after rekeying no trafic is passed through the tunnel anymore.
	This happens with both IPSEC and FAST_IPSEC kernels.

	First major problem is a different semantic in handling key information between IPSEC and FAST_IPSEC.
	There are differen key.c version for the two implementations. FAST_IPSEC will "drop" old SA's
	automaticaly from the kernel when a new one is installed. This is not done with IPSEC.
	Racoon has no chance to do the right thing for one implementation - or the implementation of racoon does
	not honor the two different semantics in the correct way.

	Then racoon does not forward DELETE messages for outgooing SA's to the kernel. This should not be
	nessesary for FAST_IPSEC, but must be done for IPSEC (as far as I understand the whole thing ...).

	Racoon does not delete SA information from the kernel if the tunnel configuration is removed. It get's the
	SPDDELETE message, but it does not identify the SA's that are no longer used and set them invalid.

	This results in the following difference in behaviour:

	IPSEC: old outgooing SA's are never removed from the kernel and it seems to be random which on is used
	       for outgooing packets.
	       The DELETE message from the client is not passed to the kernel by racoon. So the outdated SA is
	       not deleted and may be used again. But the client has dropped this SA on his side -> no communication anymore.
	       There is no DELETE message from the server to the client in any case here. The client seem to resent the
	       DELETE message some times and than give up ...
	       The kernel is collecting all outgooing SA's - the set is growing and growing ...
	       remark: I've detected packet with outdated SPI information on the network.
	       remark: you can get it working again by manualy deleting the outdated SA with setkey ...

        FAST_IPSEC: old outgooing SA's are always removed automaticaly from the kernel (if they have a livetime in setup,
	       which is always true for Windows 7 client setups, because Windows does not like it without a lifetime ...)
	       and a DELETE message is automaticaly send by the kernel to the racoon. (see PR44941 too)
	       If the client was fast enought to send the DELETE message to the Server, a DELETE message is send
	       back from the server to the client and everything is fine (if PR44941 is installed).
	       If the server has finished processing before the DELETE arrives from the client, no DELETE message
	       is send and communication stops working.
	       The kernel has always exactly on outgooing SA for the tunnel.

	remark: incomming SA's are collected in both implementations over time. There may be much more than 10 active
		SA's for incomming packets for the tunnel. After some testing I've got something around 50 incomming SA's
		in the kernel for my tunnel ...

        I do not realy understand why the IPSEC stuff works without the DELETE message from the server and FAST_IPSEC
	stopps working if it is not send, but this is the behaviour and it is reproducable.

	My knowledge on IKE protocol is poor, so I simply do not know if the DELETE responce from the server to
	the client is required or not.

	I think there are the following "misbehaviours" of the systems that keeps it from working:
	- SA's are not deleted on request by the client from the kernel (IPSEC Kame).
	  They are kept even after the tunnel has been shutdown and the corresponding SPD has been removed.
	  This may be a security issue when the next tunnel to the same IP-address is created.
	- racoon does not (IPSEC), does not always (FAST_IPSEC) sends answers for the DELETE request from the client.
	  This is at least inconsistent behavior - I assume a ISAKMP protocol-violation here.
	- for IPSEC: outgooing SA's that has expired (DELETE message from client) remains active in the kernel.

	remark: with Windows XP and NetBSD 4.0 no problems like this came up. (Not tested against 5.1 till now.)
	remark: Windows 7 clients do not work with NetBSD 4.0 too - same behaviour as in 5.1.


	One additional information what I've already tested:

	I tried to kill the automatic removal from the FAST_IPSEC kernel - just place a '#if 0' around the part in
	the source. This results in collecting all outgooing SA's in FAST_IPSEC too. FAST_IPSEC always seem to select
	the most recent SA by default (there is a variable that seems to switch this to the oldest-SA mode).
	Now no DELETE message is send by the server to the client anymore. The communication still stops "sometimes" after
	rekeying - PR44941 installed. (sorry - I've no answer to the question why this behaves like it does.)
	There seems to be another, still unrecognized reason than the DELETE message why communication breaks down.
	But haven't found any difference in the other ISAKMP messages on the network.

	If anybody can help me to get more information on the Windows 7 side, I would be glad and I'm willing to spend more
	time in debugging.
	With "netsh" I found no way to see the "Quick-Mode" SA's in detail till now. And the grafical interfaces provides
	even less information than netsh does ...
>How-To-Repeat:
	Setup a tunnel with severals subnets routed throuth the tunnel between a Windows 7 client
	and a NetBSD server and transfer a large a mount of data.
	After rekeying the communication "sometimes" stops working ...
>Fix:
	not know to me till now - sorry

	PR44941 makes FAST_IPSEC to work "sometimes" - without this PR it always stops working after rekeying.

	No sollution for IPSEC known till now - it works until rekeying occurs.
	After rekeying it only works "sometimes".

	If more information is needed to ananlyse (and fix) this problem, feel free to contact me.

>Unformatted:

Home	PR Database Search