[quagga-users 9643] Re: [quagga-dev 5493] Re: MD5 Support - 0.99.10
Michael H. Warfield
mhw at WittsEnd.com
Sat Jun 14 14:37:14 IST 2008
On Sat, 2008-06-14 at 12:12 +0100, Nick Hilliard wrote:
> > Actually, I checked, and IPV6_ONLY does seem to be present on both
> > FreeBSD and OpenBSD.
> As far as I remember, there is tcp/md5 support in the OpenBSD kernel for v6
> sockets. Most of the foundation code is there in the FreeBSD kernel too
> (i.e. the ipsec framework), but it needs some tcp/md5 specific stuff, most
> of which as far as I can tell can be ripped off from tcpdump (print-tcp.c).
> So don't assume that there will never be v6 support on *bsd for this. I,
> for one, am prepared to spend some time getting this working on freebsd
> once the kernel code is in place and working.
No no no... That's not the purpose. There was no assumption that that
there would never be v6 support for this. Just the opposite, in fact.
The purpose was to set up one socket that is IPv6 only and one socket
that was v4 (inherently only). There seems to be a corner case of the
IPv4 mapped addresses in IPv6 sockets where the MD5SIGS are not working.
Sleeping on the problem over night, I'm now wondering of that strange
code in "bgp_md5_set_passive" where the peer sa_family is AF_INET and
there is no IPv4 listen socket (bm->sock < 0) and it then creates this
new AF_INET6 socket structure to pass to the ioctl might have a great
deal to do with it. That would also make sense since the earlier
patches would have passed and AF_INET structure down on an AF_INET6
socket. Maybe, maybe, this particular code might work with a single
combined socket. Maybe that's what I was referring to earlier as a butt
ugly hack to convert between the socket types, only just the opposite
direction of what I envisioned. With the dual socket case, this code
will never get exercised. I need to remove the dual socket code and
test the single IPv6 socket case.
This may then leave Paul with two less than desirable choices, either
the socket converting code that's synthesizing the compatibility
structure in "bgp_md5_set_passive" or the dual socket code (or both).
Either way, it's just not going to magically work "out of the box"
without some consideration for cross domain issues. IAC, I'm getting a
better feel for what that "bgp_md5_set_passive" code is doing. I think
they were right. That code needs to be there.
> > Now THAT sounds remarkably like the code I saw in the OpenBSD case.
> Is this the tcp/md5 ipsec support framework in openbgpd? I'm not sure how
> portable it is in terms of API compatibility, and it would certainly make
> baby jesus cry for want of a decent ipsec API, but it does work on openbsd
> at least.
I looked at the openbgpd code to get a feel for the magnitude of the
work for the BSD case. Sounds to me like the Solaris work might be
converging on the common case from a different direction. In those
cases, the md5 signature stuff is managed in the security associations
and routines need to be set up for that and hooked into the sockopt.c in
the sockopt_tcp_signature. That remains to be done but it might be
worth waiting to see what comes out of the Solaris effort.
Paul: I'm going to retest the v10 patch minus the dual socket option.
If that works, I'll look at integrating your changes with that, but the
bgp_md5_set_passive code will probably have to remain as is.
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://lists.quagga.net/pipermail/quagga-users/attachments/20080614/b60c2f82/attachment.bin
More information about the Quagga-users