Hi, I am trying to implement BGP TTL security between one of my routers and an eBGP peer that is one hop away over a layer 2 IX. As soon as I add: neighbor 212.121.34.1 ttl-security hops 2 or neighbor 212.121.34.1 ttl-security hops 1 The peer drops to active/open sent with entries in syslog for hold time expired. I have validated via trace in both directions as being 1 hop. I have read another article that implies the default behaviour at the other end will to be send TTL 1 not 255 and consequently I need to configure both ends to get the session to come back up. An access list reveals all the packets I am receiving have a TTL of 0. The session re-establishes if I configure: neighbor 212.121.34.1 ttl-security hops >=192 <=191 and the session stays down. Which is proper bizarre! Is it necessary to configure this on both side for the session to re-establish. Is this a Cisco bug? Kind Regards Ben Butler ++++++++++++++++++++++++++++++++++++++++++ C2 Internet Ltd Globe House, The Gullet, Nantwich, Cheshire, CW5 5RL E mailto:ben.butler@c2internet.net W http://www.c2internet.net/ B1 http://c2internet.blogspot.com/ B2 http://c2noc.blogspot.com/ T +44-(0)845-658-0020 F +44-(0)845-658-0070 All quotes & services from C2 are bound by our standard terms and conditions which are available on our website at: http://www.c2internet.net/legal/main.htm#tandc C2 Internet Limited is a company registered in England and Wales with company number 03910154 Our VAT Registration number is GB 752 7650 17
On Feb 14, 2008, at 11:28 AM, Ben Butler wrote:
<=191 and the session stays down.
Which is proper bizarre!
Is it necessary to configure this on both side for the session to re-establish. Is this a Cisco bug?
You're missing the fundamentals of what protection this mechanism is meat to provide. A remote attacker can craft a packet such that it yields a TTL of 2, 1 or 0 at the target system. However, what a remote attacker can't do is craft a packet that yields a TTL or 255 or 254, for example. You probably want both values to be 254 if you've got one intermediate hop between the peers. -danny
On Feb 14, 2008, at 11:28 AM, Ben Butler wrote:
I have validated via trace in both directions as being 1 hop.
I have read another article that implies the default behaviour at the other end will to be send TTL 1 not 255 and consequently I need to configure both ends to get the session to come back up. An access list reveals all the packets I am receiving have a TTL of 0.
The session re-establishes if I configure:
neighbor 212.121.34.1 ttl-security hops >=192
<=191 and the session stays down.
Ben, After a prodding offlist I reread your message and understand what point you're making now. Indeed as you suggest above the normal configuration should be 'ttl-security hops 2' or 'ttl security hops 1'. Not for sure, but I'd have to speculate that if this is only working for you with 'ttl-security hops >= 192' perhaps your peer is setting the TTL in it's packet to 64? I believe that's the default TTL for Linux, Foundry and a couple others. Juniper's default TTL is 1 eBGP (though configurable), and 64 for iBGP, multihop, etc. IIRC. In order to implement this effectively the peer would need to be setting the transmitted TTL to 255. And my apologies if my previous message seemed a bit negative, that was certainly not my intention. -danny
participants (2)
-
Ben Butler -
Danny McPherson