Date: Wed, 4 Jan 2012 10:28:24 +0100 From: Claudio Jeker <cjeker@diehard.n-r-g.com> To: freebsd-net@freebsd.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade Message-ID: <20120104092824.GA24657@diehard.n-r-g.com> In-Reply-To: <680405C8-3323-49BC-AE59-494FC394B6F6@sarenet.es> References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> <20120103152909.GA83706@sandvine.com> <680405C8-3323-49BC-AE59-494FC394B6F6@sarenet.es>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 04, 2012 at 09:27:28AM +0100, Borja Marcos wrote:
>
> On Jan 3, 2012, at 4:29 PM, Ed Maste wrote:
>
> > Thanks for the link Nikolay.
> >
> > Borja, I assume it's the PR submission form that gave you trouble -
> > sorry for that. Based on your report it sounds to me like the bug is
> > in OpenBGPd itself. If it works on OpenBSD with the TCP_MD5SIG option
> > though I'd assume it's due to a difference in our (FreeBSD's)
> > implementation of the option. Did you look at the OpenBSD/FreeBSD
> > differences in your investigation?
>
> I looked at OpenBGPd. By the way, I was having the same issue on the different FreeBSD 9 RC's I was trying.
>
> Have a look at session.c, line 148, function setup_listeners()
>
> opt = 1;
> if (setsockopt(la->fd, IPPROTO_TCP, TCP_MD5SIG,
> &opt, sizeof(opt)) == -1) {
> if (errno == ENOPROTOOPT) { /* system w/o md5sig */
> log_warnx("md5sig not available, disabling");
> sysdep.no_md5sig = 1;
> } else
> fatal("setsockopt TCP_MD5SIG");
> }
>
> Seems that the function is using the setsockopt to check the
> availability of TCP_MD5.
>
> But, even though I haven't had a look at it on OpenBSD, I can make an
> educated guess:
>
> Behavior on FreeBSD: The setsockopt(TCP_MD5SIG) *enables* TCP_MD5.
> According to my packet captures, in case there's no properly set key
> with setkey(8) it will use whatever key. Look at the captures mentioned
> here:
>
> http://groups.google.com/group/mailing.freebsd.bugs/browse_thread/thread/ea347a919dbc165d/eeaa2965fc4f64c9?show_docid=eeaa2965fc4f64c9&pli=1
>
>
> Behavior on OpenBSD: Maybe the TCP_MD5 isn't *really* working unless
> there's a valid key associated to the socket, either using setkey(8) (I
> don't know if they use it) or via the API for setting keys.
>
>
> Whatever: Maybe FreeBSD should *ignore* that TCP_MD5SIG option for a
> socket unless (or until) a key is associated, or OpenBGPd should be
> modified so that it won't "probe" the availability of TCP_MD5SIG by
> actually setting it. Of course, if setting it for a socket is the best
> way to detect it, you can always create a temporary socket, you don't
> even need to bind() it, set TCP_MD5SIG, so that you will know if it
> succeeds or returns an error, and destroy the socket.
>
> The problem in this case is that OpenBGPd is *setting* TCP_MD5SIG on a
> socket no matter if I have configured the BGP peer with or without
> TCP_MD5. Neither Quagga nor Bird do it.
>
OpenBGPD sets the TCP_MD5SIG flag on the listening socket so that it can
be ensured that an accepted connection (SYN, SYN/ACK & first ACK) is also
protected by the TCP MD5 signature.
On startup OpenBGPD will install the necessary TCP MD5 SAs
and our network stack ensures that SAs are also matched for incomming
connections when the TCP_MD5SIG is set on the listening socket (in which
case the option is inherited to the accpeted socket).
If you can not set the TCP_MD5SIG option on listening sockets then you can
not protect and acctually accept incomming connections. A proper neighbor
would not accept the SYN/ACK sent back that does not have the MD5SIG.
How does FreeBSD avoid the chicken and egg problem of accepting
connections with MD5SIG?
--
:wq Claudio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120104092824.GA24657>