s control mechanism, with or without also using the IPSEC encryption service. It is even possible (assuming adequate processing power and an IPSEC implementation in each node) to make every machine its own IPSEC gateway so that everything on a LAN is encrypted. This protects information from everyone outside the sending and receiving machine. These techniques can be combined in various ways. One might, for example, require authentication everywhere on a network while using encryption only for a few links. Which of these, or of the many other possible variants, to use is up to you. IPSEC provides mechanisms; you provide the policy .
No end user action is required for IPSEC security to be used; they don''''t even have to know about it. The site administrators, of course, do have to know about it and to put some effort into making it work. Poor administration can compromise IPSEC as badly as the post-it notes mentioned above. It seems reasonable, though, for organisations to hope their system administrators are generally both more security-conscious than end users and more able to follow computer security procedures. If not, at least there are fewer of them to educate or replace.
IPSEC can be, and often should be, used with along with security protocols at other levels. If two sites communicate with each other via the Internet, then IPSEC is the obvious way to protect that communication. If two others have a direct link between them, either link encryption or IPSEC would make sense. Choose one or use both. Whatever you use at and below the IP level, use other things as required above that level. Whatever you use above the IP level, consider what can be done with IPSEC to make attacks on the higher levels harder. For example, man-in-the-middle attacks on various protocols become difficult if authentication at packet level is in use on the potential victims'''' communication channel.
Using authentication without encryption Where appropriate, IPSEC can provide authentication without encryption. One might do this, for example:
where the data is public but one wants to be sure of getting the right data, for example on some web sites where encryption is judged unnecessary, for example on some company or department LANs where strong encryption is provided at link level, below IP where strong encryption is provided in other protocols, above IP Note that IPSEC authentication may make some attacks on those protocols harder. Authentication has lower overheads than encryption.
The protocols provide four ways to build such connections, using either an AH-only connection or ESP using null encryption, and in either manually or automatically keyed mode. FreeS/WAN supports only one of these, manually keyed AH-only connections, and we do not recommend using that. Our reasons are discussed under Resisting traffic analysis a few sections further along.
Encryption without authentication is dangerous Originally, the IPSEC encryption protocol ESP didn''''t do integrity checking. It only did encryption. Steve Bellovin found many ways to attack ESP used without authentication. See his paper Problem areas for the IP Security Protocols. To make a secure connection, you had to add an AH Authentication Header as well as ESP. Rather than incur the overhead of several layers (and rather than provide an ESP layer that didn''''t actually protect the traffic), the IPSEC working group built integrity and replay checking directly into ESP.
Today, typical usage is one of:
ESP for encryption and authentication AH for authentication alone Other variants are allowed by the standard, but not much used:
ESP encryption without authentication Bellovin has demonstrated fatal flaws in this. Do not use. ESP encryption with AH authentication This has higher overheads than using the authentication in ESP, and no obvious benefit in most cases. The exception might be a network where AH authentication was widely or universally used. If you''''re going to do AH to conform with network policy, why authenticate again in the ESP layer? Authenticate twice, with AH and with ESP Why? Of course, some folk consider "belt and suspenders" the sensible approach to security. If you''''re among them, you might use both protocols here. You might also use both to satisfy different parts of a security policy. For example, an organisation might require AH authentication everywhere but two users within the organisation might use ESP as well. ESP authentication without encryption The standard allows this, calling it "null encryption". FreeS/WAN does not support it. We recommend that you use AH instead if authentication is all you require. AH authenticates parts of the IP header, which ESP-null does not do. Some of these variants cannot be used with FreeS/WAN because we do not support ESP-null and do not support automatic keying of AH-only connections. There are fairly frequent suggestions that AH be dropped entirely from the IPSEC specifications since ESP and null encryption can handle that situation. It is not clear whether this will occur. My guess is that it is unlikely.
Multiple layers of IPSEC processing are possible The above describes combinations possible on a single IPSEC connection. In a complex network you may have several layers of IPSEC in play, with any of the above combinations at each layer.
For example, a connection from a desktop machine to a database server might require AH authentication. Working with other host, network and database security measures, AH might be just the thing for access control. You might decide not to use ESP encryption on such packets, since it uses resources and might complicate network debugging. Within the site where the server is, then, only AH would be used on those packets.
Users at another office, however, might have their whole connection (AH headers and all) passing over an IPSEC tunnel connecting their office to the one with the database server. Such a tunnel should use ESP encryption and authentication. You need authentication in this layer because without authentication the encryption is vulnerable and the gateway cannot verify the AH authentication. The AH is between client and database server; the gateways aren''''t party to it.
In this situation, some packets would get multiple layers of IPSEC applied to them, AH on an end-to-end client-to-server basis and ESP from one office''''s security gateway to the other.
Resisting traffic analysis Traffic analysis is the attempt to derive useful intelligence from encrypted traffic without breaking the encryption.
Is your CEO exchanging email with a venture capital firm? With bankruptcy trustees? With an executive recruiting agency? With the holder of some important patents? If an eavesdropper learns that, he has interesting intelligence on your company, whether or not he can read the messages themselves.
Except in the simplest cases, traffic analysis is hard to do well. It requires both considerable resources and considerable analytic skill. However, intelligence agencies of various nations have been doing it for centuries and many of them are likely quite good at it by now. Various commercial organisations, especially those working on "targeted marketing" may also be quite good at analysing certain types of traffic.
In general, defending against traffic analysis is also difficult. Inventing a really good defense could get you a PhD and some interesting job offers.
IPSEC is not designed to stop traffic analysis and we know of no plausible method of extending it to do so. That said, there are ways to make traffic analysis harder. This section describes them.
1.Using "unnecessary" encryption One might choose to use encryption even where it appears unnecessary in order to make analysis more difficult. Consider two offices which pass a small volume of business data between them using IPSEC and also transfer large volumes of Usenet news. At first glance, it would seem silly to encrypt the newsfeed, except possibly for any newsgroups that are internal to the company. Why encrypt data that is all publicly available from many sites?
However, if we encrypt a lot of news and send it down the same connection as our business data, we make traffic analysis much harder. A snoop cannot now make inferences based on patterns in the volume, direction, sizes, sender, destination, or timing of our business messages. Those messages are hidden in a mass of news messages encapsulated in the same way.
If we''''re going to do this we need to ensure that keys change often enough to remain secure even with high volumes and with the adversary able to get plaintext of much of the data. We also need to look at other attacks this might open up. For example, can the adversary use a chosen plaintext attack, deliberately posting news articles which, when we receive and encrypt them, will help break our encryption? Or can he block our business data transmission by flooding us with silly news articles? Or ...
Also, note that this does not provide complete protection against traffic analysis. A clever adversary might still deduce useful intelligence from statistical analysis (perhaps comparing the input newsfeed to encrypted output, or comparing the streams we send to different branch offices), or by looking for small packets which might indicate establishment of TCP connections, or ...
As a general rule, though, one can improve resistance to traffic analysis by encrypting as much traffic as possible rather than only as much as seems necessary.
This also applies to using multiple layers of encr
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
