> No, IPsec does not use GRE.
You are right. I was thinking of MS' L2TP-over-IPSEC. The IPSEC header
overhead is not big. However, tunnelling RFC1918 address space over an
IPSEC connection needs something like L2TP. Every extra layer of
encapsulation adds to the overhead, though, which is why I know of several
VoIP systems that switch to frame relay (tiny packet overhead) for their
seriously bandwidth-limited channels.
> Paul> Biggest potential problem is crypto re-negotiation,
>
> We've never had this problem.
> On a properly designed VPN, new keys are established before old ones
>are removed.
Sure. I was talkng specifically abot OpenVPN, which (in my experience) has
a noticeable hiccup of several hundred milliseconds as it switches keys. I
haven't looked at the code closely, but just work around it by leaving the
session key unchanged.
I've designed and run satellite-based systems with no reliable
back-channel. In these cases we would negotiate a whole slew of session
keys whenever the backchannel was up, and switch between them randomly.
Each packet had a 16-bit header field to say which key it was using,
allowing random key selection on a packet-by-packet basis. Works really
well at securing a *very* insecure channel. AFAIK, this system hasn't been
cracked after 12 years in production (carrying sensitive financial
transaction data over a broadcast medium). This is, of course, irrelevant
to the discussion at hand.
paul
