IPSec Questions

[Rick Smith]

At 09:36 AM 8/11/99 -0400, Eric Henriksen wrote:

> .... remember that running 'Mixed Mode' AH and ESP Transport will
>result in double encapsulation.  Given the previous discussion on this forum
>regarding the impact of 'growing' the packets with additional header, ...

One gets somewhat caught between a rock and a hard place here.

IPSEC headers can protect against disclosure, modification, and replay. The
encryption transforms will only protect against disclosure. If you're a
likely victim of clever denial of service attacks (as opposed to pointed
attempts to modify specific data items in messages) then you might want the
protection of authentication. It all depends on how the level of paranoia
plays against your operational needs.

You can minimize packet size inflation by using the combined transforms, of
course, but you still have to pay the computational overhead.

>Additionally, the level of security added to the solution is unecessary
>given the resources needed to brute force attack the 3DES keys to begin
>with.  ....

You don't need to crack the key in order to replay a packet or to modify
the message contents. While these tricks won't always allow someone to
change a payment from a dollar to a million dollars, a vandal could easily
inject garbage into your system. This could cause minor glitches or major
denial of service, depending on what transaction gets corrupted.

Replaying UDP (like NFS transactions) is trivial -- you just send the
packet at a later time, assuming the same key is still being used, and the
"read" or "write" operation is repeated. Replayed TCP is more likely to be
rejected since the sequence numbers might not make sense (though Bellovin
wrote up something about how an attack might circumvent this problem).

Packet modification is straightforward with typical stream ciphers like
RC4: you flip bits in the ciphertext and the same bits get changed in the
plaintext. Fix the packet checksum and you're done. Block ciphers with CBC
are also vulnerable, though you'll usually end up with several bytes of
garbage at the point where the new data is spliced in.

If hijacking is your only concern, then you should get by just fine with
encryption. A good hijack would need to recover the key. However, the
mechanisms needed for hijacking would support garbage insertion with less
effort.


Rick.
smith at securecomputing.com
"Internet Cryptography" at http://www.visi.com/crypto/

****************************************************************
TO POST A MESSAGE on this list, send it to vpn at listserv.secnetgroup.com

The VPN FAQ (under construction) is available at
http://kubarb.phsx.ukans.edu/~tbird/FAQ.html

We are currently experiencing "unsubscribe" difficulties.  If you
wish to unsubscribe, please send a message containing the single line
"unsubscribe vpn your-e-mail-address" to owner-vpn at listserv.secnetgroup.com

****************************************************************