[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.