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

Michael H. Warfield mhw at WittsEnd.com
Thu Jun 19 17:27:07 BST 2008

Ok Paul...

	I've been really busy getting ready for the FIRST (Forum of Incident
Reaction Security Teams) conference up in Vancouver, where I'm speaking,
and have been distracted.  I really should have tested this days ago.

On Thu, 2008-06-19 at 16:12 +0100, paul at clubi.ie wrote:
> On Tue, 17 Jun 2008, paul at clubi.ie wrote:

> > Do we know whether it works?
> >
> > 2008/06/17 00:01:43 BGP: sockopt_tcp_signaturemapping AF_INET into AF_INET6
> > 2008/06/17 00:01:43 BGP: sockopt_tcp_signature: adding ::ffff:, 
> > 4

> > But tcpdump shows that packets sent from the accept socket have an invalid 
> > TCP-MD5 signature..

> So does anyone know, or do I just commit and let people investigate 
> this later? ;)

	Ok...  Forgetting about your revisions to the v10 patch for the moment,
I went back to the v10 patch which included the contributions from two
others including that bgp_md5_set_passive code.  I took out the dual
socket code and set two systems talking with each other.  It did not
work.  Which really tells me the magical "AF_INET -> AF_INET6" code in
bgp_md5_set_passive is not doing the trick.  When I looked at it, I
though that might be the answer.  I think the problem is still the
kernel calculating the md5 signature seed over an IPv6 pseudo header and
getting the wrong seed value.  Then you're screwed.  But the real answer
still comes back to multiple sockets, one for each protocol family.

	I did notice that, either way, I'm able to talk to the Cisco gear I
have to talk to.  But that's because, while the connection from them to
me may come in on an IPv6 socket on my end with mapped addresses and
fail, I connect back to them on IPv4 and it works.  So this failure mode
is limited to peers where both parties have the same mapped address
problem.  IOW...  Quagga to quagga.  But that's a fluke of having both
peers trying to contact each other.

> (I'd *MUCH* rather confine Linux specific behaviour to linux specific 
> code..).

	Well, now, lets think about this.  You keep referring to "linux
specific code" but it seems to be the dual socket code is the more
generic case.  This will work on FreeBSD and OpenBSD, both of which have
the IPV6_V6ONLY flag.  What I DON'T know (does anybody know) if the
corner case of the IPv6 mapped address work on those platforms?  So we
have code which will work on all those platforms or we have code which
will not work on one platform (linux) and may or may not work on two
others.  I'm actually trying to see what's "linux specific" about this.

	We could limit the dual socket code to the platforms where MD5SIGS is
defined, since it would appear to be an MD5SIG behavior more than
anything else.

	My recommendation would be to proceed with your cleanups but leave that
"bgp_md5_set_passive" code in there and leave the dual socket code in
there.  In that case, in the "bgp_md5_set_passive" code where we have an
AF_INET peer and no AF_INET socket we're listening on (bm-sock == -1)
will never occur.  That code branch seems to be useless.  With dual
sockets, it's never executed and with a single AF_INET6 socket, it
doesn't work, AFAICT.

	What would be the downside to having multiple sockets, one per address
family, in any case, other than esthetics?  It's the one case that's
most likely to work in the widest variety of environments.

> regards,
> -- 
> Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
>  	http://www.quagga.net/commercial.php#jakma
> Fortune:
> This is the ____LAST time I take travel suggestions from Ray Bradbury!

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/20080619/0e4667c8/attachment-0001.sig>

More information about the Quagga-dev mailing list