-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jeffrey Haas Sent: Friday, April 01, 2011 9:12 AM To: [email protected] Subject: [sidr] IETF 80 - suggestions related to expiry time and BGP implementation
2. Short expiry times are an attack on the routing system, especially boxes with slow signature processors. Routes that will expire "soon" should be refreshed with enough time so that receiving peers can take their own sweet time to validate that a new valid path has been received in spare cycles. [WEG] Along those same lines - I think we need a global minimum value for beacons to reduce the exposure to this DoS attack (on the validating router) vector. We already have scaling issues when too many eBGP peers set their BGP timers too aggressively on the same box, and that is at least locally controllable by enforcing a minimum in the negotiated session. There's no negotiation happening here, and therefore no way to protect those routers, short of ignoring updates, which generates stale routes and probably churn (depending on the policy). In fact, this starts looking a lot like the Route Flap Dampening problem we're trying to solve elsewhere in IETF - a very small amount of the prefixes might be responsible for an overwhelming majority of the updates to the detriment of the routing system's performance. Even if it's just a refresh, there's a non-trivial impact if too many people start being overly paranoid about their expiry times. But by the same token, being too conservative with the expiry means that there is a longer period of exposure where a replay would be effective, and the value of implementing the overhead at all starts becoming questionable. How long is too long for a replay attack to go unnoticed? I'd bet that a lot of the folks worried about this would answer in minutes, while those concerned primarily with the hardware in their routers would answer in hours... This is an area where any info we have about the prevalence of replay attacks and their characteristics would be really helpful in determining how much risk we are preventing by addressing this specific attack vector vs how much overhead we're generating with this expiry machinery. Thanks, Wes George
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
