[quagga-dev 5496] Re: [quagga-users 9626] MD5 Support - 0.99.10

Michael H. Warfield mhw at WittsEnd.com
Sat Jun 14 04:04:42 BST 2008

On Fri, 2008-06-13 at 22:29 +0100, paul at clubi.ie wrote:
> On Sat, 14 Jun 2008, YOSHIFUJI Hideaki / 吉藤英明 wrote:

> > Quagga always converts IPv4 peer as sockaddr_in{} if accept() gives 
> > ipv4-mapped ipv6 address (sockaunion_accept()). Kernel does not 
> > accept bare sockaddr_in{} for TCP_MD5SIG. If Quagga tries to set 
> > MD5 Signature using peer->su, it will fail.

> Aha.. and using the v4-mapped sockaddr_in6 would work?

	We are already.  That's the point.  That happens automatically and
that's what the ::FFFF:n.n.n.n address is.  It's IPv4 mapped into IPv6.
That's the case that's broken.

> We could fix that I think.

	Yeah.  The fix is to use two sockets thus avoiding the v4-mapped
sockaddr_in6 case.

> > If you set IPV6_V6ONLY socket and have 2 sockets (one for IPv6 and 
> > the other is for IPv4) for BGP, problem should go away because IPv4 
> > traffic is handled by the IPv4 socket natively.

> Or we could just stop converting between sockaddrs ;) (I'm assuming 
> the only reason for that is to have v4 addresses printed as v4, 
> rather than v4-mapped-in-v6).

	Nope...  Just backwards.  The reason is to have an IPv6 application
receive an IPv4 connection on an IPv6 socket and be able to handle it.
It reenforces the idea that we have to avoid this case.  Avoiding this
case means having two sockets, one listening on IPv4 only and one
listening on IPv6 only.  Not so much because of the socket behavior but
because of the setsockopt behavior.

	You'll notice in the setsockopt call for TCP_MD5SIG a pointer to the
sockunion structure is passed with the password and all the addresses.
Why would they need that if they were merely storing a password with a
socket.  Answer is - they're not.  They're computing the md5hash seed
based on the tcp pseudo header as constructed from the sockaddr
structure plus the password.  That can be stored with the socket address
tuple and applied to matching packets where they start with the seed and
continue with the payload and never recompute the sum over the pseudo
header.  You could argue that the ioctl function should recognize those
addresses as being compatibility addresses and convert to a different
header before computing that seed, but I wouldn't bet the farm on that
particular bit of cross domain behavior.

	I'm concerned that even if we brow beat some people into agreeing that
it's a bug (and Yoshfuji just demonstrated the argument they will use
against our argument) it will be even more difficult to get them to
implement the cross domain code to fix it.  I seem to recall some
arguments from Dave Miller (I could be wrong on that) to the effect that
the md5sig code itself would go into the kernel over his dead cold body
(just BECAUSE it's only used by this one application), but we eventually
got it.

	Ok...  This is going to sound weird but I MIGHT have an interesting
little experiment to test.  If I had a connected AF_INET6 socket with
IPv4 compatibility addresses, what might be possible is to construct a
sockaddr structure for AF_INET with the appropriate lower 32 bits of
each v6 address as the v4 addresses and pass THAT to setsockopt for the
TCP_MD5SIG function.  That way it would know it had an AF_INET structure
and create the appropriate pseudo header to create the initial md5sum
over.  I'm betting that would work but, IMNSHO, that's an even uglier
butt ugly hack than having two sockets.

> regards,
> -- 
> Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
>  	http://www.quagga.net/commercial.php#jakma
> Fortune:
> He keeps differentiating, flying off on a tangent.

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: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20080613/85520d56/attachment-0001.sig>

More information about the Quagga-dev mailing list