user/2996: PF_KEY_ACQUIRE messages are misunderstood by ISAKMPD

>Number: 2996
>Category: user
>Synopsis: PF_KEY_ACQUIRE messages are misunderstood by ISAKMPD
>Confidential: no
net
>Environment:

        System      : OpenBSD 3.2
        Architecture: OpenBSD.i386
        Machine     : i386

There is an inconsistency in the semantics for ipsec flows and the way ISAKMP parses them. A flow specified as: ipsecadm flow -require -addr 0.0.0.0 0.0.0.0 10.0.0.1 255.255.255.255 -out is fully specified. In particular, the flow says to require ipsec from anywhere (typically us with a dynamic IP address, but anyone else who uses us as a gateway) to 10.0.0.1. There is no "gateway" specified by a "-dst" flag, because we are using IPSec transport instead of tunneling.

The flow is added and processed by the kernel just fine. However, when ISAKMPD
receives the SADB_ACQUIRE message, SADB_EXT_ADDRESS_SRC and SADB_EXT_ADDRESS_DST are both all-'0' struct sockaddr's.

Line 3077 (and subsequent lines) of ISAKMPD pf_key_v2.c assumes dstaddr will be an AF_INET or AF_INET6 sockaddr, which is not necessarily true (it may
be 0). If it is not true, the "Peer-" name generated on line 3520 is completely invalid, causing ISAKMPD to fail.

Line 3102 shows the author understands that EXT_ADDRESS_SRC may not be specified. However, the if statement is invalid--the kernel ALWAYS sends an all-'0' struct sockaddr, so 'if (src)' will never evaluate false--instead the case statement falls through a non-existent 'default' breaking the "Peer-" name again.

In short, the kernel sends acquire messages which are not properly parsed by ISAKMPD. There is a bias towards assuming there is a "destination" and that
IPSec tunneling is being used, whereas IPSec transport does not require a destination.
>How-To-Repeat:

Add an ipsec transport flow:
ipsecadm flow -require -addr 0.0.0.0 0.0.0.0 10.0.0.1 255.255.255.255 -out Run ISAKMPD
telnet to 10.0.0.1

Notice the peername is "Peer-/" which is really wrong. :-)
>Fix:

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related openbsd.org Links advocacy announce bugs ipv6 misc ports ports-changes security-announce smp source-changes tech Request more information about Pantek

This patch will allow you specify flows without explicit -src or -dst. You can even specify non-specific flows (such as: ipsecadm flow -require -addr 0.0.0.0 0.0.0.0 10.0.0.1 255.255.255.0 -out which would definitely NOT work without this patch).

Index: pf_key_v2.c
3076a3077,3085
> if (dstaddr->sa_family == 0) {
> /* Destination was not specified in the flow--can we derive it? */
> if (dhostflag == 0) {
> log_print("pf_key_v2_acquire: Cannot determine precise
destination");
> goto fail;
> }
> dstaddr = dflow;
> }
>

3124a3134,3141
> break;
> default:
> /* The kernel will pass an all '0' EXT_ADDRESS_SRC if it wasn't
> * specified for the flow. In that case, do NOT specify the
srcaddr
> * in the Peer- name below
> */
> srcbuf[0] = 0;
> srcaddr = NULL;

>Release-Note:
Received on Thu Nov 28 09:44:04 2002