[Xorp-users] MD5 Support

[Bruce M Simpson]

--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--