Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 31 Jan 2008 05:19:35 +0000
From:      "Bruce M. Simpson" <bms@FreeBSD.org>
To:        Ingo Flaschberger <if@xip.at>
Cc:        "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, freebsd-net@freebsd.org
Subject:   Re: tcp-md5 check for incomming connection
Message-ID:  <47A15A67.9000605@FreeBSD.org>
In-Reply-To: <alpine.LFD.1.00.0801310106400.723@filebunker.xip.at>
References:  <alpine.LFD.1.00.0801291905020.17757@filebunker.xip.at> <479FF09B.4050705@FreeBSD.org> <20080130083105.S36482@maildrop.int.zabbadoz.net> <alpine.LFD.1.00.0801310106400.723@filebunker.xip.at>

next in thread | previous in thread | raw e-mail | index | archive | help
The bigger issue w/tcp-md5 is getting security policy 'right'.
bz has more IPSEC hacking experience than I, so I defer to his advice in 
this area.

The way the socket option was originally specified was that once it was 
set, all further activity on the socket had to be tcp-md5'd. For an 
outgoing connect() this is pretty much assumed in the beginning. For a 
listen() and bind(), it means all further sessions on that port must use 
tcp-md5 to be accepted.

However this obviously poses problems if you want to be able to accept 
connections on the same port from non tcp-md5 peers. And for BGP, which 
can open the underlying tcp session in either direction ('passive open', 
jittered) it's also important that the tcp-md5 state of the socket is in 
sync with the routing process's notion of policy.

ospf sidestepped all this by using raw IP datagrams, so there was no 
need to implement authentication in the network transport layer.

So, the SPD seems like the way to go! Trouble is, routing daemons aren't 
IPSEC daemons, nor do they speak the RFC specified protocol for this, 
PF_KEY. I toyed with the idea of rolling one for XORP but there hasn't 
been any demand.

cheers
BMS



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47A15A67.9000605>