Hi again,

Sorry, I forgot one last thing: "the tcpdump support" from Bruce ;-)
   http://people.freebsd.org/~bms/dump/tcpdump-rfc2385/

Regards,
  Vincent

On Wednesday 21 April 2004 21:56, Vincent Jardin wrote:
> Hi,
>
> I think that is would be nice if this API could be compatible with the
> FreeBSD and the OpenBSD one. Both use "TCP_MD5SIG".
>
> It can be tested using:
>   http://people.freebsd.org/~bms/dump/quagga-tcpmd5/
>
> FYI:
> 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 incom- 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
> neces- sary for the administrator to add a tcp-md5 key entry to the
> 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 failed 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
> must be a decimal number, or a hexadecimal number with ``0x'' prefix. SPI
> values between 0 and 255 are reserved for future use by IANA 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.
>
> For 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
> 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?