quagga 0.99.8 on current, tcpmd5 config confusion

[Bruce M. Simpson]

Randy Bush wrote:
> just did a cvsup build and portupgrade of a six month old -current
> i386 system running quagga.  quagga cranked to 0.99.8.  i got
> slammed by bgp tcpmd5 requirement.
>
> bgpd[469]: can't set sockopt TCP_MD5SIG 0 to socket 17
> bgpd[469]: can't set sockopt TCP_MD5SIG 0 to socket 18
> bgpd[469]: can't set sockopt TCP_MD5SIG 0 to socket 22
>
> madly googled and found that i needed to hack kernel for tcp md5
> hash, even though i am not using md5 auth (these are not really
> infrastructure peerings.  yes i know better for production).
>   

This I haven't seen before, then again, it's been years since I've used 
Zebra/Quagga let alone hacked the patch for md5 support, which is now 
~3.5 years old. It was only ever intended as a belt-and-braces attempt 
at getting things up in a way which the sponsor was satisfied with, with 
no other refinements.

I wasn't 100% happy about how I ended up doing the kernel support, and 
had to go with what I had working in my tree because of that old demon 
'economics', rather than doing things 'the right way': i.e. in the IPSEC 
Security Policy Database (SPD), with the routing daemon loading the 
keys, rather than the Security Associations Database (SADB) and keys 
loaded manually using setkey(8).

Other individuals have since made changes to this code. Now that we have 
settled on FAST_IPSEC thanks to gnn's hard work, it will be easier for 
Someone(tm) to pick this up, as KAME IPSEC and FAST_IPSEC interfaced to 
key sockets differently enough to change the implementation of the SPD.

> with this kernel, i got a lot of whining about no keys
>
> tcp_signature_compute: SADB lookup failed for 666.42.69.96
>   

I remember putting in the SADB lookup failed message to help people 
track down problems with their configuration. If TCP_MD5SIG is not 
enabled on the tcp socket, no SADB lookup should happen, so you 
shouldn't be seeing this message.

It sounds to me as though Quagga may be enabling the TCP_MD5SIG option 
unconditionally based on all of the output you've posted. This is 
obviously incorrect. I can't speak for Quagga, though it seems 
reasonable to suggest that it shouldn't be doing that unless you tell it 
to. I believe the MD5 patches only get pulled in if you request them, 
and that md5 auth specifically needs to be enabled per peer.

Still, this is nearly 4 years on and I have other things going on now.

regards,
BMS