Well in a perfect world (One which IP6 is supposed to be.) You don't have to reset a gateways MTU size to allow IPSec pass though. I know that has been an issue especially if you have DSL with PPPoE. One of the things that confuses some people who use IPSec in a IPv4 world. Is when you have RFC1918 addressing on both sides of the tunnel that match. I.E. 192.168.1.X on both sides of the tunnel. I've run into this while trouble shooting IPSec issues before. I think that their is a place for SSL based VPN solutions. I just don't have a high level of diffidence that SSL will remain a valid in-transit encryption protocol.
--mmiller On Wed, Oct 20, 2010 at 5:14 AM, Carlos Perez <[email protected]> wrote: > by replay I meant about fragmented packets and lost of packet due to MTU > sizes and having to be re-sent, I used the wrong terminology. > On Oct 19, 2010, at 10:05 PM, Butturini, Russell wrote: > >> What kind of replay problems Carlos? Last time I checked ESP contained >> anti-replay controls that solved this issue. Are there new attacks? Would >> love to hear more. >> >> One of the great things with IPSec in tunnel mode is that you can >> pre-classify the traffic with QoS markings before encryption, and then have >> these values copied to the post encapsulated header (great for softphones >> etc.). There's not a lot of flexibility for this with SSL VPN, at least in >> the appliances I've seen on the market. Our experience has been too that >> you need to scale up more to support SSL, IPSec clients tend to be less >> resource intensive, but a lot of that depends on the encryption algorithms >> in use. >> >> We're sticking with IPSec for now. It's tried and true and we have no >> reason to change. >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Carlos Perez >> Sent: Tuesday, October 19, 2010 8:37 PM >> To: PaulDotCom Security Weekly Mailing List >> Cc: [email protected] >> Subject: Re: [Pauldotcom] SSL vs IPSec VPNs >> >> SSL Strip does not work on a full SSL VPN, I have tried ;), I would say it >> depends on the traffic, amount of traffic and how time sensitive is that >> traffic. SSL over UDP gives the best performance but you have a big pain of >> certs and cert validation to minimize the attack surface, on the IPSEC >> depending on the implementation you can get the most compatibility for >> different client types but on high traffic with time sensitive traffic you >> will get fragmentation and possible replay problems. There are a lot more >> pros and cons but after 5 days of hospital I'm bone tired from sleeping on a >> chair, when I get coffee in me in the morning I will try to expand on the >> points. >> >> Cheers, >> Carlos >> >> On Oct 19, 2010, at 9:41 AM, Michael Douglas wrote: >> >>> Hey all, >>> >>> I'm trying to determine what protocols should be permitted on a new >>> VPN concentrator. >>> >>> I'd like to stick with IPSec, it's tried and true, and to quote Garth: >>> "We fear change". However, it seems that all the vendors are going >>> down the SSL route. Now I know SSL is 'safe', but it seems like it's >>> more open to attacks like SSLStrip (thanks again Moxie for making us >>> aware of the problems!) I get that SSL is easier for administrators >>> and end users alike, but is that convenience at too high a cost? >>> >>> So what are your thoughts? Am I being too paranoid? If there are >>> articles or places where I should RTFM, that's cool... I just need to >>> know what FM to read!! Please send the links/info ;-) >>> >>> >>> Thanks for your input, and have a nice day! >>> - Mick >>> _______________________________________________ >>> Pauldotcom mailing list >>> [email protected] >>> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom >>> Main Web Site: http://pauldotcom.com >> >> _______________________________________________ >> Pauldotcom mailing list >> [email protected] >> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom >> Main Web Site: http://pauldotcom.com >> >> >> ****************************************************************************** >> This email contains confidential and proprietary information and is not to >> be used or disclosed to anyone other than the named recipient of this email, >> and is to be used only for the intended purpose of this communication. >> ****************************************************************************** >> _______________________________________________ >> Pauldotcom mailing list >> [email protected] >> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom >> Main Web Site: http://pauldotcom.com > > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com > _______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
