EBGP Multihop TTL vs. TCP accept()

[Peter Hessler]

On 2017 Aug 16 (Wed) at 21:17:22 +0200 (+0200), Matthew Walster wrote:
: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

in OpenBGPD, we set the TTL related socket options before we call
listen(), so it is always set before the connection happens.


-- 
Anyone can do any amount of work provided it isn't the work he is
supposed to be doing at the moment.
		-- Robert Benchley