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.
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 rating system on the key 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
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Iljitsch van Beijnum Sent: Monday, June 19, 2006 10:22 AM To: Randy Bush Cc: NANOG list Subject: Re: key change for TCP-MD5
On 19-jun-2006, at 19:10, Randy Bush wrote:
try reading more carefully
Didn't help...
how sad, as the whole document is about how to usefully be able to introduce and roll to new keys without agreeing on a narrow time.
Well, as you can tell from my message just now, I don't think going from agreeing on a narrow time to agreeing on a wider time is worth the trouble, especially since by adding a BGP message it would be possible to roll over if and as soon as both sides are ready, removing the "wait for some time and then see whether the other end really installed the new key" part from the proceedings.
On Tue, Jun 20, 2006 at 05:06:27PM -0400, Ross Callon wrote:
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.
I'd still like someone to explain why we're wasting man hours, CPU time, filling up our router logs, and potentially making DoS easier, for an attack that doesn't exist. After that, I'd like them to explain why we need to devote more resources to protecting against the attack that already doesn't exist, and that is already protected against just fine even if it were to exist. Of course any not completely insane implementation should be checking for a valid TCP window range (or an existing TCB for that matter) before wasting CPU time on an MD5 calculation. It's just not possible in reality for any sufficiently large number of packets to get through those check to then be affected by an MD5 DoS (unless of course you're peering with 7018, and the NSA has an extra copy of your packets laying around). We already collectively wasted our time deploying MD5 passwords over a big scare that turned out to be nothing more than someone cracking open the manual and rediscovering how stuff worked all along. Why don't we spend our time going forward solving actual issues like filtering/announcement authentication, and stop trying to solve the non-existant problems. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
On Jun 20, 2006, at 4:29 PM, Richard A Steenbergen wrote:
We already collectively wasted our time deploying MD5 passwords over a big scare that turned out to be nothing more than someone cracking open the manual and rediscovering how stuff worked all along
Bwahahahhahaha. I work with that "someone" --- he (and the rest of his group) are wildly proud of this "l33t discovery" W
. Why don't we spend our time going forward solving actual issues like filtering/ announcement authentication, and stop trying to solve the non-existant problems.
-- Richard A Steenbergen <ras@e-gerbil.net> http://www.e- gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
-- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. -- J.R.R. Tolkien
I'd still like someone to explain why we're wasting man hours, CPU time, filling up our router logs, and potentially making DoS easier, for an attack that doesn't exist.
because the non-existent attack(s) have occurred. and keys have been compomised. randy
At 07:29 PM 6/20/2006 -0400, Richard A Steenbergen wrote:
On Tue, Jun 20, 2006 at 05:06:27PM -0400, Ross Callon wrote: ...I'd still like someone to explain why we're wasting man hours, CPU time, filling up our router logs, and potentially making DoS easier, for an attack that doesn't exist....
I think that it does make sense to be clear what attack or set of attacks we are trying to protect against. One type of attack is the TCP reset attack. I personally don't have a strong opinion regarding whether it is worth protecting against only this attack. Another potential attack is an attempt to insert information into a BGP session, such as to introduce bogus routes, or to even become a "man in the middle" of a BGP session. One issue that worries me about this is that if this allows routing to be compromised, then I can figure out how to make money off of this (and if I can think of it, someone even nastier will probably also think of this). Of course this would be much more difficult to pull off, and might require viewing packets between routers to pull off, but if pulled off and not quickly detected could be unfortunate. Ross
--- Ross Callon <rcallon@juniper.net> wrote:
Another potential attack is an attempt to insert information into a BGP session, such as to introduce bogus routes, or to even become a "man in the middle" of a BGP session. One issue that worries me about this is that if this allows routing to be compromised, then I can figure out how to make money off of this (and if I can think of it, someone even nastier will probably also think of this). Of course this would be much more difficult to pull off, and might require viewing packets between routers to pull off, but if pulled off and not quickly detected could be unfortunate.
But it's safe to say that it would be a lot easier to crack a router itself than to unobtrusively insert useful false information, or if the ISP's routers are sufficiently hardened, it would be easier to crack a customer (or peer)'s router, and use that for the injection. The same mechanisa which can detect bogus prefixes from a peer/customer can detect them from a hijacked session. The cost/benefit ratio is better for securing the routers themselves. -David David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
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 rating system on the key 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).
gstm
On Tue, Jun 20, 2006 at 05:18:20PM -0700, Randy Bush wrote:
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 rating system on the key 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).
gstm
this doesn't help if the vendor can't implement it correctly and does the md5 calc before checking the ttl :( - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
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 rating system on the key 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). gstm this doesn't help if the vendor can't implement it correctly and does the md5 calc before checking the ttl :(
hard to imagine anything that will help such a vendor randy
On Tue, 20 Jun 2006 17:06:27 -0400, Ross Callon <rcallon@juniper.net> wrote:
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.
You're quite right, and the next version of the draft contains the following additional text in the Security Considerations: Having multiple keys makes CPU denial of service attacks easier. This suggests that keeping the overlap period reasonably short is a good idea. In addition, the Generalized TTL Security Mechanism <xref target="RFC3682" />, if applicable to the local topology, can help. Note that there would almost never be more than two keys in existence at any one time in any event. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
participants (7)
-
David Barak -
Jared Mauch -
Randy Bush -
Richard A Steenbergen -
Ross Callon -
Steven M. Bellovin -
Warren Kumari