| |
We have seen SSH in chapter 7. Note that most arguments we make about SSL is also valid for SSH. Both SSL and IPsec approach has its own advantages and disadvantages and the decision of the layer to implement security is application-dependent. The following is a list of guidelines for decision makers:
- The philosophy of SSL is that it is easier to deploy something if you do not have to change the operating system. Note that layer 4 (e.g. TCP) and below are implemented in the operating system.
- The philosophy of IPsec is that implementing security within the operating system automatically causes all applications to be protected without the applications having to be modified.
- Security protocols working above TCP have the following problem. If a malicious data with a correct TCP checksum is inserted into the packet stream, there is no way to notice this at the TCP layer. Only SSL will be able to discard it but since TCP has already accepted malicious data as the real data, when the real data is sent TCP will assume it is duplicate and discard it. The only solution for SSL is to close the connection which brings the possibility of launching denial-of-service attacks.
- On the other hand, IPsec has also a drawback. With the currently used API, it cannot tell the application anything more than the IP address on the other end. Distinguishing between users which is demanded in most cases is possible with IPsec but would require changing the application. This means to take full advantage of IPsec, applications will have to change.
- For an outboard device, it is easier to implement IPsec than to implement SSL since for SSL implementation, it is required to implement the protocol stack up to and including the relatively more complex TCP protocol.
|
|
|
