EBGP Multihop TTL vs. TCP accept()
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
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
participants (2)
-
Matthew Walster -
Peter Hessler