I have been doing some tests with BGP and I have found that the Mikrotik routers are unable to use the RFC 3682 TTL security option.

The classical TTL security is based on using a low TTL, generally 1, for single-hop BGP connections. The measure is effective preventing a BGP connection from being established from a peer more than one hop away, but it still has a drawback: packets with a TTL of 1 are trivial to spoof, so rogue packets will still reach the router.

This would be harmless except for the potential for resource consumption attacks against TCP connections protected with MD5. The router must verify the MD5 signature of packets it receives.

RFC 3682 suggests the opposite approach: instead of using a TTL value of 1, it suggests a value of 255 and discarding any packets received with a TTL of less than 255. Doing that, it's not possible to inject valid packets from a remote location as long as none of the devices in the local network is compromised in some way.

The measure is easy to implement. On systems that, unlike FreeBSD, lack a setsockopt() option to set a minimum TTL on a socket, it's possible to use a firewall filter rule to drop packets with a smaller TTL.

However, this measure currently does not work on Mikrotik routers because during the TCP connection exchange they send the SYN+ACK packet with a default TTL of 64. That means that the peer starting the connection will drop the SYN+ACK and it won´t work.

I have done the same test on a Juniper router running JunOS and, despite having a default ttl of 64, they have done a hack to send SYN+ACK packets with a TTL of 255. That allows the three way exchange to complete.

It would be nice to have this simple change made. As I said, a TTL of 255 is a better way to protect a BGP router against multi-hop connections.

I know this is not exactly what you are looking for, but you can change the TTL of any packets from your MikroTik using Mangle.

This work-around could be used at least temporarily to achieve what you describe.

I didn't realize that. Thank you very much indeed!