Re: Whitepaper: a closer look on what goes on behind the scene during the setup of a IPSec remote access VPN

[Christopher Lee <complexity () bigfoot com>]

Brian,

Thank you for your very kind words.  Well, RFC 2408 basically dictates how 
vendors (should) implment their technologies, but as you could tell, more and 
more vendors starting to blend in their own "enhancements" to it so that kinda 
defeats the purpose of the "Standard".

I am fairly confident that, apart from the "Transaction Config mode" exchange, 
ISAKMP should behave pretty much the same way for any "shared-secret" based 
remote access VPN implmentation.  This conclusion come as the result of knowing 
I could use non-CheckPoint VPN clients (PGPnet, IRE client and etc) to talk to 
CheckPoint VPN gateways, and CheckPoint gateways' ability to integrate with 
other vendors' VPN gateways (as long as the other vendors offers full tunning 
abilities on the parameters for phase I and phase II exchanges, since their 
default parameters are always slightly different).

> From my experiences, most of the VPN problems (between vendors) comes from the 
ability to have both of them talking on the same parameters.  Most vendors has 
come a long way to make themselves more compatible with the RFCs specs 
(comparing what it was in '97-'99).  The most problems I have encountered are 
mostly to do with the SA parameters (mostly the default life of the keys).  I 
mean, every vendors now support the encryption algorithm of DES/3DES, and the 
hasking algorithm of MD5/SHA-1, but it's often the refresh interval is what 
messes things up.  The symptons are often "The VPN tunnel is up for a while and 
then breaks down for no reason, then comes up again with any intervention"...

I don't know if I am going to add in discussions about too much vendor specific 
troubleshooting details.  That work has already been very well done on serveral 
firewall/vpn mailling lists, and it would be silly for me trying to replicate 
their efforts (which took years, and the inputs of many subject experts in 
their respective fields).  My white paper was geared to fill in the gap between 
FAQs from the VPN mailing list (which is very generic and high level), the 
vendor's own support knowledge base (which focus more on their own prodcut 
instead of the technology) and the RFC (too much technology and too dry).

Yes, if there are any folks on the list that could give me (access) to 
information that I have already found, I would be more than happy to update the 
white paper with it (and, of course, be greately appreciate by yours truely).  
After all, this white paper starts as my personal quest to make clear about 
this widely used, but often mis-undestood technology.

Regards,

Christopher Lee
PGP Fingerprint: 15C1 65D0 E051 C64D 5246  89FC 5AE3 DE2C 8F1E 89A7
Personal Web Page: http://complexity.webhop.net


Quoting Brian Ford <brford () cisco com>:

> Christopher,
>
> I think you've done an admirable job of presenting IPsec as it could be 
> used for remote access connectivity and based on my limited knowledge a 
> good job covering how Check Point may use IPsec to establish a client 
> connection.  It's very good work.  I think it's a bit of a stretch to say 
> that all IPsec implementations work this way after looking at only one 
> commercial vendors product.  I suggest you should address that in your
> title.
>
> I'd be interested in hearing your perspective of where this breaks 
> down.  What are the most common causes for connections to not establish or 
> to fail?  It would be especially interesting to look at that given your 
> study of the RFCs.  An often asked question when things break: Is it the 
> vendors implementation or something not covered in the RFC.
>
> You may want to look at the work done by (and perhaps talk to) the folks at
>
> ICSA Labs (http://www.icsalabs.com), as they  offer an IPsec 
> Interoperability program that many vendors subscribe to in order to test 
> their products conformance to the RFCs and ability interoperate with other 
> vendors implementations.   There are people from the Labs on this list.
>
> Good job.
>
> Liberty for All,
>
> Brian
>
>
> At 09:42 AM 1/7/2002 -0500, firewall-wizards-request () nfr com wrote:
> > Message: 3
> > Date: Sat,  5 Jan 2002 22:39:27 -0500
> > From: Christopher Lee <complexity () bigfoot com>
> > To: firewall-wizards () nfr com
> > Subject: [fw-wiz] Whitepaper: a closer look on what goes on behind the 
> > scene during the setup of a IPSec remote access VPN
> >
> > To the member of the Firewall-Wizards list,
> >
> > Throughout this Christmas/New Year holidays, I finished reading a few
> InfoSec
> > related books and I find myself ending up with more questions than 
> > answers.  I
> > mean, how does the two phase IPSec key exchange really works (packet by 
> > packet,
> > that is)...  I mean, how does IPSec guard against replaying attack, or
> more
> > fundamentally, how do I know if my login credentials are safe when the 
> > firewall
> > is doing an Aggressive Mode key exchange (no encryption takes place during
> an
> > aggressive mode key exchange)??
> >
> > So I then do my own research, base only on documents on the IETF websites
> (a
> > reliable source, I supposed) and the result of my own sniffer trace of a 
> > IPSec
> > remote access VPN session, and come up with this little white paper on
> what
> > goes on behind the scene during a IPSec VPN setup.  I figure, the best way
> to
> > make sure I understands a technologies correctly is to post my finding on
> the
> > web and invite others to critique and comment upon.
> >
> > While the example in this white paper is that of a CheckPoint VPN, but its
> > principle should conver IPSec VPN in general.  Please take a look at this 
> > paper
> > when you get a chance and do drop me a line (and tell me how wrong I am
> about
> > the subject).  :-)
> >
> > This white paper is posted on
> > http://complexity.webhop.net/closer_look_at_IPSec.html
> >
> > Regards,
> >
> > Christopher Lee
> > PGP Fingerprint: 15C1 65D0 E051 C64D 5246  89FC 5AE3 DE2C 8F1E 89A7
> > Personal Web Page: http://complexity.webhop.net


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards