BGP TTL Security Check

[grunky]

In light of the recent tcp window vunerability I looked around for other ways, besides md5 auth, to secure my BGP sessions. I ran across this:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s27/s_btsh.htm

I thought this would be a great way to secure BGP sessions as most BGP peers are within the same subnet, ie each peer only needing a TTL of 1 to communicate. However the docs on this appear backwards to me..

-----

This feature protects the eBGP peering session by comparing the value in the TTL field of received IP packets against a hop count that is configured locally for each eBGP peering session. If the value in the TTL field of the incoming IP packet is greater than or equal to the locally configured value, the IP packet is accepted and processed normally. If the TTL value in the IP packet is less than the locally configured value, the packet is silently discarded and an ICMP message is not generated.

-----

Shouldn't this be the other way around?? ie If ip packet has TTL greater then say 2 then drop the packet w/ no ack/response?

If I have a BGP session setup like w/ the peers addresses being

192.168.0.1

192.168.0.2

in a /30 AND if I configure

router bgp 100

no synchronization

bgp log-neighbor-changes

neighbor 192.168.0.1 remote-as 100

neighbor 192.168.0.1 ttl-security hops 2

no auto-summary

The above statement w/ docs say a spoofed packet, supposivly from 192.168.0.1, w/ a ttl of say 20 is perfectly fine, even though we'd know that can't be true because the TTL is just way to high.

Shouldn't the ttl-security hops parameter be a MAX ttl? instead of the min?

The section marked:

Verifying the TTL-Security Check Configuration: Example

gave the bold output

External BGP neighbor may be up to 2 hops away.

which implies a upper limit. I think they flip-floped this in the middle of the docs.

Is this the correct interpretation? If I'm flat wrong someone please explain this to me...

Thanks.

[ruwhite]

Nope, this is the right direction. The idea is that your bgp peer would originate packets with a TTL of 255. So, say you have this:

A---B---C---D

Now, A and B are BGP peers. B is originating BGP packets with a TTL of 255, and A expects the packets it receives from B to have a TTL of at least 254 (maybe 253 in some situations/implementations). No matter what TTL D sticks on the packet when it originates it, it can't get the packet to A with a TTL over 253, so A will always reject D's BGP packets.

If you set A to not accept anything with a TTL over, say, 2, then D could always originate packets with a TTL of 3, and they would be 1 (or 0) when they get to A, and thus A would accept them.

:-)

Russ.W

[grunky]

Ok thanks for the explanation Russ. I assumed that packets in the same subnet would have a ttl that would be set low because they wouldn't be routed anyway. If packets being sent to hosts in the same subnet have a ttl of 255 then the docs make much sense.

The problem is on the page they have the example given of

neighbor 192.168.0.1 ttl-security hops 2

Acording to what you're saying - shouldn't that be at 253???

[ruwhite]

Oh yes, well, that.... :-) That number is the number of hops, not the actual TTL, so to find the actual TTL, you'd subtract that number from 255. I know, it's confusing.... :-( The key is here:

External BGP neighbor may be up to 2 hops away

In the output. That tells you that you assume the peer is always setting the packets with a TTL of 255, and that the peer may be up to 2 hops away, so 255-2 == 253.

:-)

Russ.W