Robert Moskowitz wrote:
>
>>> I have never liked the SSLvpn architecture. Never really liked the SSL
>>> handshake; just too chatty. I wear my biases quite plainly on my arm
>>> sleeve (I chaired the IPsec workgroup during the time the RFCs came
>>> out). You want security, go with IPsec. Even ESP NULL gives you per
>>> packet authentication and thus proof of server and client. Just pay the
>>> price for IKE, which I never liked. Part of the reason I invented HIP....
>>>
>> But ssl vpns work though just about any firewall/proxy/nat that already
>> permit https. Traversing those can be painful or impossible for ipsec.
>
> The problem is NATs (so speaks a co-author of RFC 1918!). SSL vpns
> tunnel networking over Transport. Gee I wonder why that works through NATs?
Or, given the near-universal use of NATs, you have to wonder about the
viability of anything that doesn't traverse them gracefully.
> Part of the NAT traversal mess contributed to my drive for HIP which the
> actual developers realized needed a different ESP mode: BEET. Of course
> even HIP needs ICE to find things out there and to be found....
I'm not sure what any of those acronyms means, but the other problem
with IPsec is that the usual tools don't provide an interface for
routing and they need some other mechanism to decide what goes through
them. On Ciscos I've always set up GRE tunnels to get something the
routing protocols can see, then crypto-mapped the GRE packets. Is there
a common computer implementation that would mesh with this?
--
Les Mikesell
lesmikesell at gmail.com