rfc2385 (tcp md5 checksums) in -current broken?

[othermark]

I am posting this to -net since I got zip response on -current...               

Hi,

I'm testing rfc2385 support with some of our equipment with current as of a
few days ago, and the support seems, well, rather broken.

I have the following options in my kernel
options     TCP_SIGNATURE           #include support for RFC 2385
options     FAST_IPSEC
device      crypto

and have loaded the following entry via setkey:

add 172.16.17.1 172.16.18.164 tcp 0x1000 -A tcp-md5 "password" ;

but when I dump a test link to the inetd tcp echo server, I get no
connection.   The dump shows the sending box 172.16.18.164 has the correct
signature for the shared secret (with the tcpdump -M option), but the
FreeBSD boxes response shows invalid.

12:46:25.377320 IP 172.16.18.164.50850 > 172.16.17.1.echo: S
371298114:371298114(0) win 4380 <mss 1460,md5:valid,eol>
12:46:25.377401 IP 172.16.17.1.echo > 172.16.18.164.50850: S
3974454780:3974454780(0) ack 371298115 win 65535 <mss 1460,nop,wscale
1,nop,nop,timestamp 1400471 0,md5:invalid,eol>

Now it could be that the tcp stack is just sending garbage for the MD5
option when it receives it on a socket that doesn't have some sort of 
socket option configured (which would be bad).

othermark
atkin901 at nospam dot yahoo dot com
(!wired)?(coffee++):(wired);