C150's Are not Ready for Email Encryption Prime Time
We have been working with an issue with out C150's and email encryption. Believe it or not the below items have been confirmed with Ironport Support:
1. The C150's have a bug that make them run out of memory and fail during encryption of messages IF more than approx 2 >5MB messages are submitted at about the same time. Hardly what I would call "extreme" throughput. 2. The C150's have a bug that make them unable to send an encrypted email that can be opened on the other side (using the java applet) if there is an attachment greater than about 5MB or so. 3. Placing the C150's into "Online" mode, bypassing the applet, results in about 57 minutes to open a 10MB attachment (with a 10MB down, 2MB up connection).
I would love for any C150 owners to send a 8-10MB attachment to themselves and post a reply on times to open (if you can open at all).
I would love to be wrong on ALL points.
Buyer Beware at this point. So far we have had about $12,000 of paperweights now for 5 months.
I have confirmed all above points with tech support and development.
I just wanted to be fair and post that I have started making some support contacts at Ironport that seem very interested in fixing the issues. Only time will tell, but I do now feel that Ironport is 100% behind making this right.
Re: C150's Are not Ready for Email Encryption Prime Time
Gary, I'm one of the Product Managers on the Encryption team and I wanted to follow-up on your post and the phone conversations you had with our group last week.
I believe you're testing a fix for out-of-memory issue now. How is that going? We're working with a few other advanced customers who have run into the same problems that you described and they are having good luck. The patch is on-track for release in our 6.1 roll-out which should GA in February.
The Java applet issue caught us off-guard when there was an update to the Java runtime engine used in most current web browsers that caused memory usage to go through the roof. Our envelope team has been investigating this in-depth since it first cropped up. Right now the recommendation that we have posted to our customer support and technical field is that they recommend customers use the "Open Online" feature to avoid the Java memory issue. We're still going to fix that one though.
For the open online performance, when I first heard about this it was a bit of a mystery. We've tested this extensively from a number of different networks and never found that it should take more than a few minutes to complete the decryption of an attachment. Since the data does have to go from your desktop, up to the server, and then back down though it is possible that there was a temporary network slowdown somewhere between your site and Cisco that choked things up. We have a network monitoring service in place that tells us when this occurs from a number of pre-determined sites around the world. If you still see latency please let us know so we can determine if we need to add more monitoring locations.
And yes, IronPort is absolutely 100% behind addressing these issues. As always, we appreciate your feedback and help. Please let us know if there's anything else we can do at this point.
Rand Wacker Group Product Manager email@example.com
I have 121 entries in our logs today for the Java Out of memory bug. This is with the patches installed. It is hard to say if this is "better" or not yet. I am not sure yet if the messages are still bouncing with an NDR like they were before. The users here got used to simply waiting and trying to re-send.
Tue Jan 15 10:12:41 2008 Critical: PXE encryption - Thread-10533, daemon.RequestThread, Can't execute STATUS command (java.io.IOException: Broken pipe), closing down
I think MANY of the problems opening online (or with the applet for that mater) are due to the issue of a lack of progress bar when you first open the securedoc.html. I recorded and sent in a video that showed a 3 minute BLANK screen when attempting to open C:\securedoc.html..... no progress bar, no "please wait" no nothing. I think an update should be made that always displays some sort of "please wait" dialog. Most users will not wait 3 minutes for a process to complete... especially with no signs that it is even running. I think many users simply close, and try to re-open over and over and over.......... This only happens with larger attachments (over 5MB).
With an 8MB attachment, it can take more than a couple of minutes just to open the Envelope (Just to the to the point where you can enter a password and click "Open Online).......
I would not think that it would take nearly this long. I am on a quad core box with 3GB of ram. I understand that sending 8MB to cisco and getting 8MB back will take some time... but rendering the envelope locally should not take 3 minutes......
Re: C150's Are not Ready for Email Encryption Prime Time
As we appreciate all your feed back and test cases on this issue. We can assist faster if you post this information into the ticket. If these issues are noted in the ticket everyone in support and engineering are kept in the loop. Please be sure to update the ticket with future findings so we can assist you faster in this ongoing task.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...