[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Should CPE allow all IPsec through? Was: Re: CPEs



Hmm. Dumb question.

It seems to me that there is an excellent attack in this. If I know that a given address (perhaps found in the envelope of an email I have observed) is populated and attempt to open an IPsec session, I consume some amount of computing resource. If I do that a lot, I can consume a large quantity of computing resource. I can obviously also consume other resources including bandwidth of various kinds.

There are some mechanisms that we use in mail filtering, in which we identify a relatively small set of IP addresses that are highly likely to be business partners on matters of business, and with all others we apply some level of prejudice - known nogoodnicks have their SYN ignored, and unknowns get a higher level of scrutiny than common business partners. My IT department tells me that "ignoring SYNs" dumps about 75% of traffic to Cisco, and the additional scrutiny dumps over 80% of the rest before it ever gets to the MUA. I in my case the final MUA (the beysian filter in my email client) is still dumping an average of 58 emails a day, which if the IT folks' statistics right means that they are sheilding me from something on the order of 2000/day. I can tell you of days (SOBIG.F comes to mind) in which I received over 6000 emails, mostly junk, in a matter of a couple of hours, so that doesn't seem too far out in the weeds.

I'm envisioning the same basic attack, but in setting up IPsec sessions. I wonder what the best approach would be. I have little to no expectation that my Infosec department is going to even *think* about opening the firewall to let that class of attack through - they would view the suggestion as somewhere between idiocy and lunacy. 58 spurious sessions getting through and not being about to authenticate with my system in the course of a day is one thing (still high, but survivable); a focused attack of multiple thousands of sessions per day ongoing 24X7 is simply not on.

How would you suggest preventing that attack from ever getting to the host and retain the ability to connect into the host from outside the domain?

The thing that comes to mind depends on frequently-changed privacy addresses - if I use a previously-unused privacy address for every minute during which I open new sessions and let old ones expire, pulling addresses out of emails won't be much of an attack surface. But that doesn't address any matter in which the host is legitimately expecting to be contacted from outside its domain, and it still leaves the attack on the router on that LAN.

On Jan 8, 2008, at 9:04 AM, Iljitsch van Beijnum wrote:

[Response to other issues will follow]

On 8 jan 2008, at 17:44, Bound, Jim wrote:

One filter I believe will become required will be end-to-end IPsec and it is just let through, but for corporate and government markets there could become decrypt capability supporting the media line rates without performance degradation, and I believe we will see this form of DPI in the home CPE too. The other data point I see happening is as peer-2-peer moves further users will want the option to encrypt at their device to an application function and other devices, thus the filter is if IPsec and secure (big question for sure) then let it pass. Ergo no filters at all for this case. The firewall becomes a security manager with far more intelligence than today.

There has been some talk about letting all IPsec through regardless of statefulness, but I don't remember a clear conclusion.

However, this does seem to be an attractive option in the sense that it allows for a way to have peer-to-peer communication without giving up security. It would probably still need some selling to some security-conscious groups, but a good argument there would be that there is no reasonable way that an attacker could get anywhere without first negotiating a security association, but if we don't implement this, that simply means applications will use less secure peer-to-peer mechanisms.