On Jan 31, 2008 7:19 AM, Bruce M. Simpson <[EMAIL PROTECTED]> wrote:
> 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.
>OpenBGPD on OpenBSD seems to do exactly this. It supports the PF_KEY interface and one can configure either TCP_MD5_SIG or IPSEC security associations for the bgp peers right in the bgpd.conf config file. -- Niki _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
