EBGP Multihop TTL vs. TCP accept()

[Matthew Walster]

Hello,

I've just spent a while trying to debug a BGP session not coming up with
bird, it turns out I had mistakenly set the multihop setting to "1" instead
of "2" -- my fault.

However, the reason it took me so long to realise this error was because
the TCP session is established, with default connection parameters, THEN
the TTL limit is assigned to the skb. As far as I'm aware, with TCP sockets
in both Linux and BSD, the connections are already established when
accept() returns a new connection.

As I understand it, that's why inbound connections can't be filtered by the
incoming source address either until the TCP session is already
established, which usually means iptables/pf rules on the box synced with
whoever the configured peers are. Which tends to lead to log spam when
[known security company] does yet another scan of global address space for
open BGP neighbours and fires a bunch of alerts...

This may be a case of "that's just what you have to live with" but I was
wondering if there's an alternative? Obviously libwrap0 (tcp-wrappers)
won't help here because that also just processes a rule-set after accept()
-- it's presumably something that needs to be addressed in the kernel. In
any case, you can't set the TTL on a listen() for the SYN-ACK that is
returned on a SYNC as far as I'm aware, unless you modify the default TTL
for all TCP connections, you can't even set it with "ip route" or "route"
on a per-destination basis.

How do other people handle this situation? Do they create
iptables/pf/whatever rules dynamically generated from their bird.conf for
neighbor access control? How about ebgp multihop -- or does everyone just
set it to 16/64 and forget about it? Or do people largely not care?

M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20170816/0806c6ec/attachment.html>