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

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


On Sat, 2008-06-14 at 00:03 +0100, paul at clubi.ie wrote:
> On Fri, 13 Jun 2008, Michael H. Warfield wrote:

> > has me really confused.  Now, instead of setting the password on 
> > the connected peer's socket, that's setting the password on the 
> > listen socket after copying the address structure from the peer's 
> > socket.

> Well, setting or changing the password clears a session. So any time 
> you set, the session almost certainly has to be down - only the 
> listen socket then needs to have the password applied. An outbound 
> BGP connection gets the password set in bgp_connect().

	Actually, you don't need a password set on the listen socket, and
that's just the point.  With no password set, the initial SYN is
received and the listen socket signaled while the MD5 signature is
ignored (on just that one packet).  The accept socket is where the
password is needed to return the SYN-ACK with the appropriate signature
and to set the socket up for the session.  But that would appear to have
a questionable timing issue.  If the accept causes the SYN-ACK to be
immediately returned, how can you set the password for that before
executing the accept.  Chicken - Egg...  Except it might be (should be)
caught on the retry, but that's butt ugly to put it kindly.  But that
was working, so I'm not sure about the timing and the semantics at this
point.

	Actually, I'm a even more concerned now with that bgp_md5_set_passive
and what Yoshfuji mentioned about the md5sum and the  headers.  I'm now
having a bad feeling that the md5sig table is not tightly coupled to the
socket, as one might assume, but to the address/port tuples, which would
have almost the same effect, except with this nuggie SYN-ACK case.  That
implies that almost any valid "socket" would do to set an MD5SIG entry,
since you're providing the complete saddr/sport daddr/dport to the ioctl
call.  I may have to go "dumpster diving" in the kernel code itself to
figure out why it's doing what it's doing and when with what.

	That also implies that the MD5SIG is being seeded by the md5sum over
the pseudo header derived from the sockaddr structure provided.  That
would explain the problem with the compatibility addresses.  The ioctl
is not doing a translation from the compatibility address v6 header to
it's equivalent v4 header to compute that seed.

	That explains the API behavior we see.

> Still wondering if we really need the seperate v6 socket though 
> (IPV6_ONLY isnt too portable afaict, and non-portable hacks reduce 
> test-coverage).

	Actually, I checked, and IPV6_ONLY does seem to be present on both
FreeBSD and OpenBSD.  So it may be more portable that what I first
assumed.  That logic should work in Linux and the BSD's.  I don't know
about the Solaris case, which you noted is under active development.
IAC, having separate sockets for the v6 and v4 protocol families does no
harm in any case.

> regards,
> -- 
> Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
>  	http://www.quagga.net/commercial.php#jakma
> Fortune:
> "It's like deja vu all over again."   -- Yogi Berra
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev at lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-dev

	Mike
-- 
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/225d42b1/attachment-0001.sig>


More information about the Quagga-dev mailing list