North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: key change for TCP-MD5
- From: Iljitsch van Beijnum
- Date: Sat Jun 24 06:17:09 2006
On 24-jun-2006, at 1:34, Patrick W. Gilmore wrote:
If you care that much, why don't you just add an extra loopback
address, give it an RFC 1918 address, have your peer talk BGP
towards that address and filter all packets towards the actual
interface address of the router?
The chance of an attacker sending an RFC 1918 packet that ends up
at your router is close to zero and even though the interface
address still shows up in traceroutes etc it is bullet proof
because of the filters.
Why is this better than using the TTL hack? Which is easier to
configure, and at least as secure.
There are several tradeoffs. GTSM (or "TTL hack") requires that both
ends implement it and this check may or may not be inexpensive.
(Looking at the CPU stats when running with MD5 and then looking up
how fast MD5 is supposed to be processed on much older hardware
doesn't give me much confidence in router code efficiency.)
If you're truly paranoid, making sure that as few people as possible
can enter packets into your router's CPU input queue makes a lot of
sense. I prefer having a regular next hop address that shows up in
traceroutes and can generate PMTUD packets but if you move the BGP
session to some other address there is no need for the interface
address to ever receive any packets. That's a lot better than
expending resources on AH processing, which I was replying to.
RFC 1918 are an obvious choice for the addresses terminating the BGP
session because they're mostly unroutable by default, but an address
range that's properly filtered by your peer is even better.
And if you're on a public peering LAN (internet exchange) obviously
you'll want to have static ARP and MAC forwarding table entries.