[BUG] pfkey implementation vs. RFC

[DuBuisson, Thomas]

I've posted this to linux-net and netdev but have had no response.  If there
is any confusion about what the bug is then just e-mail me for
clarification.  If this is an intentional omission then could someone let me
know why.

Section 3.1.6 of RFC 2367 clearly indicates there are two 
cases in which user space programs can send the kernel pfkey 
'acquire' messages.  The first case is just the 'struct sadb_msg' 
header that should specify an error relating to a previous 
acquire message.  The second case is intended for use by routing
daemons and the like.  This case is not implemented in the Linux 
kernel - I have reprinted the relevant portion of the RFC below:
 
------------------
   The third is where an application-layer consumer of security
   associations (e.g.  an OSPFv2 or RIPv2 daemon) needs a security
   association.

        Send an SADB_ACQUIRE message from a user process to the kernel.

        <base, address(SD), (address(P),) (identity(SD),) (sensitivity,)
proposal>

        The kernel returns an SADB_ACQUIRE message to registered sockets.
 
        <base, address(SD), (address(P),) (identity(SD),) (sensitivity,)
proposal>

        The user-level consumer waits for an SADB_UPDATE or SADB_ADD
        message for its particular type, and then can use that
        association by using SADB_GET messages.
----------

As one can see in net/key/af_key.c:pfkey_acquire() the only acquire messages
accepted are of format <base> and with errno != 0.

Now for the barrage of questions:
Was this omitted for a reason?
Are we aware this was omitted?
Does someone already have a patch?
Would a patch be accepted for 2.6.13 if it is sent in time?  
This is a bug after all.
 
Cheers,
Thomas

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/