FW: BGP TTL Security

14 Feb 2008

      Hi Danny,

Thanks for you help - no problems.

I would agree 192 vs 63/64 it is to much of a coincidence for it not to
be related somehow.

Weirder and weirder - presumably people trying to hack the BGP session
below:

neighbor 212.121.34.1 ttl-security hops 192

And the session is up and we get:

Extended IP access list ACL-MATCH-TTL-0/254 (Compiled)
    10 permit ip any any ttl eq 0 (869 matches)
    20 permit ip any any ttl eq 1 (1 match)
    260 permit ip any any ttl eq 25 (1 match)
    580 permit ip any any ttl eq 57 (1 match)
    590 permit ip any any ttl eq 58
    600 permit ip any any ttl eq 59
    610 permit ip any any ttl eq 60
    620 permit ip any any ttl eq 61 (2 matches)
    630 permit ip any any ttl eq 62 (2 matches)
    640 permit ip any any ttl eq 63 (1 match) <- presumably the foundry
    1210 permit ip any any ttl eq 120 (2 matches)
    1220 permit ip any any ttl eq 121 (2 matches)
    1230 permit ip any any ttl eq 122 (1 match)
    1240 permit ip any any ttl eq 123 (1 match)
    1250 permit ip any any ttl eq 124 (1 match)
    2500 permit ip any any ttl eq 249 (6 matches)
    2510 permit ip any any ttl eq 250 (3 matches)

This is connected to an ethernet IX and all peers are one hop away.

Kind Regards

Ben 

-----Original Message-----
From: Danny McPherson [mailto:danny@tcb.net]
Sent: 15 February 2008 01:16
To: Ben Butler
Cc: Hank Nussbacher
Subject: Re: BGP TTL Security

On Feb 14, 2008, at 6:12 PM, Ben Butler wrote:
...
Hi,
I have put a route map on the interface and matched every TTL from 0 
to
254 and I am only getting matches on TTL 0.
Is the ttl-security check still in place?  I believe the way Cisco
implemented that is that if the TTL doesn't match the prescribed value
then they expire the TTL to drop the packet in the fast path.
...
The box on the other side in this particular instance is a high end 
Foundry.
I don't really care about the 192 thing because I will never have 
mutlihop peers that far away - it was simply an observation.
Well, that's quite a coincidence because Foundry's default IP TTL value
is 64, which is quit suspicious.
...
The problem is needing to configure both sides of the peering and 
consequently on a per session basis / cordinatition which means a lot 
of work and inertia of organising other people to roll out the change.
Hrmm... On other thought..

Is the Foundry a multi-hop peer?  If so, perhaps in their configuration
they're specifying ebgp multli-hop 1, which is triggering this behavior?

But I'd suspect the above rather than this, because of the
192 behavior.

Thoughts?

-danny