nanog mailing list archives
RE: key change for TCP-MD5
From: "Bora Akyol" <bora () broadcom com>
Date: Tue, 20 Jun 2006 16:23:12 -0700
Good comments, please see inline:
-----Original Message----- From: Ross Callon [mailto:rcallon () juniper net] Sent: Tuesday, June 20, 2006 2:06 PM To: Bora Akyol; nanog () merit edu Subject: RE: key change for TCP-MD5 At 12:12 PM 6/20/2006 -0700, Bora Akyol wrote:The draft allows you to have a set of keys in your keychain and the implementation tries all of them before declaring the segment as invalid.DoS against routers is of course a major concern. Using encryption has the potential of making DoS worse, in the sense that the amount of processing that a bogus packet can cause is increased by the amount of processing needed to check the authentication. If the router needs to check multiple keys in the keychain before declaring the segment as invalid, then this multiplies the effect of the DOS by the number of keys that need to be checked.
Ross The DOS is a concern whether you have a valid key or not, correct? I can DOS the router with fake packets that it needs to verify as long as I want. All the multiple keys do is to decrease the cost of the DOS. For example, if we allow 4 keys at a time and the router dies at a 100 Mbps attack traffic, now it will die at 25 Mbps. While this may look like a big deal, I think the dark side has enough firepower that essentially 25 equals 100. For device vendors, they need to solve this problem regardless of the number of simultaneous key checks. For example, they can use a TCP-offload-engine for their CPU. The TOE engines are being used in servers for a long time now. If DOS is such a large concern, IPSEC to an extent can be used to mitigate against it. And IKEv1/v2 with IPSEC is not the horribly inefficient mechanism it is made out to be. In practice, it is quite easy to use.
No time synchronization required. No BGP message required. The added cost for CPU-bound systems is that they have to try (potentially) multiple keys before getting the **right** key but in real life this can be easily mitigated by having a ratingsystem on thekey based on the frequency of success.This mitigates the effect of authenticating valid packets. However, this does not appear to help at all in terms of minimizing the DOS effect of an intentional DoS attack that uses authenticated packets (with the processing time required to check the keys the intended damage of the attack). Ross
Please see my comments above. Regards Bora
Current thread:
- RE: key change for TCP-MD5, (continued)
- RE: key change for TCP-MD5 Ross Callon (Jun 20)
- Re: key change for TCP-MD5 Richard A Steenbergen (Jun 20)
- Re: key change for TCP-MD5 Warren Kumari (Jun 20)
- Re: key change for TCP-MD5 Randy Bush (Jun 20)
- Re: key change for TCP-MD5 Ross Callon (Jun 21)
- Re: key change for TCP-MD5 David Barak (Jun 21)
- Re: key change for TCP-MD5 Richard A Steenbergen (Jun 20)
- RE: key change for TCP-MD5 Randy Bush (Jun 20)
- Re: key change for TCP-MD5 Jared Mauch (Jun 21)
- Re: key change for TCP-MD5 Randy Bush (Jun 21)
- RE: key change for TCP-MD5 Ross Callon (Jun 20)
- Re: key change for TCP-MD5 Steven M. Bellovin (Jun 26)
- RE: key change for TCP-MD5 Randy Bush (Jun 21)
- Re: key change for TCP-MD5 Iljitsch van Beijnum (Jun 21)
- Re: key change for TCP-MD5 Niels Bakker (Jun 25)
- Re: key change for TCP-MD5 Iljitsch van Beijnum (Jun 26)
- RE: key change for TCP-MD5 Randy Bush (Jun 21)
- Re: key change for TCP-MD5 Richard A Steenbergen (Jun 21)
- backbone threats [Re: key change for TCP-MD5] Pekka Savola (Jun 26)