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>