Date: Wed, 11 Aug 2004 21:07:45 -0700 From: Bruce M Simpson <bms@spc.org> To: Nathan K <doesnotcount@hotmail.com> Cc: freebsd-net@FreeBSD.org Subject: Re: [Xorp-users] MD5 Support Message-ID: <20040812040745.GA781@empiric.icir.org> In-Reply-To: <BAY19-F146mTBb5VYUd0002573c@hotmail.com> References: <BAY19-F146mTBb5VYUd0002573c@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Crossposted to freebsd-net by way of FAQ material] On Wed, Aug 11, 2004 at 01:05:32PM -0400, Nathan K wrote: > Are there plans (or work in progress) to support TCP MD5 connectivity=20 > between BGP Peer Routers? This is likely to be an FAQ, so please consider this message authoritative FAQ material for the time being. I committed preliminary support for this to XORP over the past week. This is more or less a direct port of the work I did on Quagga. Currently there are some restrictions. 1) All the XORP support does is enable and disable the use of the TCP_MD5SIG socket option for BGP *active opens*, that is, outgoing peer connections. This socket option is 'de facto' standardized across the open source BSD= s. The password argument is effectively ignored, just as for the Quagga support. This will not be the case in future, hopefully (see below). 2) You will need to set up a security association containing the key for the TCP-MD5 session via the use of the setkey(8) command on FreeBSD. The means for doing this will vary across BSDs; I believe ipsecadm(8) is appropriate for OpenBSD, whereas setkey(8) will work on NetBSD. On FreeBSD, there is an example in the setkey(8) man page. Future Directions for XORP -------------------------- What I'd like to do in future is introduce PF_KEY support to XORP, probably as an extension of the infrastructure which the FEA module provides. The reasons for this are twofold. One, it will allow XORP to control TCP-MD5 security associations directly. Two, it will provide us with the infrastructure needed to control things like IPSEC associations in future if we chose to introduce this functionality into XORP. As PF_KEY is somewhat standardized (RFC 2367 Informational) and well documented (UNIX Network Programming Vol1 2e Fenner et al) this is a portable way of achieving this across the BSDs. Linux (FreeS/WAN et cetera) may be another story. Future Directions for TCP-MD5 ----------------------------- Recently, itojun considerably expanded on my work, in the NetBSD tree. I have a crossport of this further work to the FreeBSD tree which is almost complete but needs further testing. This adds support for KAME IPSEC as well as FAST_IPSEC, and TCP over IPv6, and the input verification path. This work will not be merged into FreeBSD until after the 5.3 branch. There are a few issues with the current state of this work in that it's impossible to conduct non-TCP-MD5 and TCP-MD5 protected sessions over the same TCP socket in LISTEN state without effectively denying non-TCPMD5 connections. This is the reason for the unavailability of TCP-MD5 with regards to BGP passive opens at this time. I have a fork of my original code which attempts to address this by placing policies into the SPD, rather than relying on a TCP protocol-level socket option. itojun's further hacking makes the SPD method easier to implement. The SPD fork of my patch set is unstable. The reason for this is that SPI granularity is impossible with TCP, as it has no notion of an SPI field, which is specific to IPSEC AH/ESP. This would however require that applications such as Quagga and XORP speak fluent PF_KEY in the BSD dialect. Regards, BMS --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBGu0QueUpAYYNtTsRArjiAJ0SHCP7LDBUonHWDO+XfPNfQsEUWgCgnJPM xmLRquk0wbsJWltBMnn8RvY= =EnyM -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040812040745.GA781>