kern/44962: IPSEC/FAST_IPSEC and racoon does not work reliable with Windows 7 Clients

[Wolfgang.Stukenbrock%nagler-company.com@localhost]

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