Hi,

I think that is would be nice if this API could be compatible with the Free=
BSD=20
and the OpenBSD one. Both use "TCP_MD5SIG".

It can be tested using:
  http://people.freebsd.org/~bms/dump/quagga-tcpmd5/

=46YI:
man 4 tcp (FreeBSD):
     TCP_MD5SIG  This option enables the use of MD5 digests (also known as
                 TCP-MD5) on writes to the specified socket.  In the current
                 release, only outgoing traffic is digested; digests on inc=
om-
                 ing traffic are not verified.  The current default behavior
                 for the system is to respond to a system advertising this
                 option with TCP-MD5; this may change.

                 One common use for this in a FreeBSD router deployment is =
to
                 enable based routers to interwork with Cisco equipment at
                 peering points.  Support for this feature conforms to RFC
                 2385.  Only IPv4 (AF_INET) sessions are supported.

                 In order for this option to function correctly, it is nece=
s-
                 sary for the administrator to add a tcp-md5 key entry to t=
he
                 system's security associations database (SADB) using the
                 setkey(8) utility.  This entry must have an SPI of 0x1000 =
and
                 can therefore only be specified on a per-host basis at this
                 time.

                 If an SADB entry cannot be found for the destination, the
                 outgoing traffic will have an invalid digest option
                 prepended, and the following error message will be visible=
 on
                 the system console: tcp_signature_compute: SADB lookup fai=
led
                 for %d.%d.%d.%d.

man 8 setkey:
     protocol
             protocol is one of following:
             esp         ESP based on rfc2406
             esp-old     ESP based on rfc1827
             ah          AH based on rfc2402
             ah-old      AH based on rfc1826
             ipcomp      IPComp
             tcp         TCP-MD5 based on rfc2385

     spi     Security Parameter Index (SPI) for the SAD and the SPD.  spi m=
ust
             be a decimal number, or a hexadecimal number with ``0x'' prefi=
x.
             SPI values between 0 and 255 are reserved for future use by IA=
NA
             and they cannot be used.  TCP-MD5 associations must use 0x1000
             and therefore only have per-host granularity at this time.
[...]
    example:
   add 10.1.10.34 10.1.10.36 tcp 0x1000 -A tcp-md5 "TCP-MD5 BGP secret" ;

The cvs log from FreeBSD was:
revision 1.93
date: 2004/02/11 04:26:02;  author: bms;  state: Exp;  lines: +19 -0
Initial import of RFC 2385 (TCP-MD5) digest support.

This is the first of two commits; bringing in the kernel support first.
This can be enabled by compiling a kernel with options TCP_SIGNATURE
(in fact, it has been changed to TCP_MD5SIG) and FAST_IPSEC.

=46or the uninitiated, this is a TCP option which provides for a means of
authenticating TCP sessions which came into being before IPSEC. It is
still relevant today, however, as it is used by many commercial router
vendors, particularly with BGP, and as such has become a requirement for
interconnect at many major Internet points of presence.

Several parts of the TCP and IP headers, including the segment payload,
are digested with MD5, including a shared secret. The PF_KEY interface
is used to manage the secrets using security associations in the SADB.

There is a limitation here in that as there is no way to map a TCP flow
per-port back to an SPI without polluting tcpcb or using the SPD; the
code to do the latter is unstable at this time. Therefore this code only
supports per-host keying granularity.

Whilst FAST_IPSEC is mutually exclusive with KAME IPSEC (and thus IPv6),
TCP_SIGNATURE (TCP_MD5SIG) applies only to IPv4. For the vast majority of=20
prospective users of this feature, this will not pose any problem.

This implementation is output-only; that is, the option is honoured when
responding to a host initiating a TCP session, but no effort is made
[yet] to authenticate inbound traffic. This is, however, sufficient to
interwork with Cisco equipment.

Tested with a Cisco 2501 running IOS 12.0(27), and Quagga 0.96.4 with
local patches. Patches for tcpdump to validate TCP-MD5 sessions are also
available from me upon request.

Regards,
  Vincent


On Wednesday 21 April 2004 21:17, Matt Thomas wrote:
> At 04:59 PM 4/20/2004, Jeff Rizzo wrote:
> >So, last summer (Late May) there was some discussion about RFC 2385
> >support ("Protection of BGP Sessions via the TCP MD5 Signature") which
> >had been written but not committed due to lack of time on the part
> >of the developer(s) who had written it.  Is there someone I can buy a
> >beer or two to persuade to revisit this?  :)  It would be nice to
> >be able to continue to use NetBSD for BGP applications now that many
> >peers are demanding MD5 session authentication...
> >
> >Yes, IPSec would be more appropriate, but since the 500lb gorilla
> >supports this way...
> >
> >Thanks!
> >+j
>
> I have an implementation that I did a few years ago.  The real
> question is where do you get your MD5 keys from?  Use PF_KEY?  Allow
> to be set via a setsockopt?
>
> The latter is nice for a simple use.  But if you have a listener
> which needs to use different keys depending on the foreign address
> you need something more complex.
>
> Sadly, setkey(8) and PF_KEY will need some work to support MD5 keys.
>
> So what capabilities are needed?