1.IKE的phase 1和phase 2 IKE Phase 1 The basic purpose of IDE phase 1 is to authenticate the IPSec peers and to set up a secure channel between the peers to enable IKE exchanges.IKE phase 1 performs the following functions: --Authenticates and protects the identities of r IPSec peers --Negotiates a matching IKE SA policy between peers to protect thd IDE exchange --Performs an authenticated Diffie-Hellman exchange with the end result of having matching shared secret keys --Sets up a secure tunnel to negotiate IKE phase 2 parameters When the IKE negotiation begins,IKE looks for an IKE policy that is the same on both peers.The peer that initiates the negotiation will send all its policies to the remote peer,and the remote peer will try to find a match.The remote peer looks for a match by comparing its own highest priority policy against the other peer's received policies.The remote peer checks each of its policies in order of its priority(highest priority first)until a match is found. A match is made when both policies from the two peers contain the same encryption,hash,authentication,and Diffie-Hellman parameter values,and when the remote peer's policy specifies a lifetime less than or equal to the lifetime in the policy being compared.(If the lifetimes are not identical,the shorter lifetime-from the remote peer's policy-will be used.) If no acceptable match not found,IKE refuses negotiation and IPSec will not be established. If a match is found,IKE will complete negotiation,and IPSec security association will be created. IKE Phase 2 The purpose of IDE phase 2 is to negotiate IPSec SAs to set up the IPSec tunnel.IKE phase 2 performs the following functions: --Negotiates IPSec SA parameters protected by an existing IDE SA --Establishes IPSec security associations --Periodically renegotiates IPSec SAs to ensure security --Optionally performs an additional Diffie-Hellman exchange 2. data integrity --The receiver can verify that the data was not altered during transit. data confidentiality --Only entities permitted to see the data will have the capability to view the data. authentication --The receiver can determine the source of the packet,guaranteeing and certifying the source. replay protection --The receiver can verify the correct sequence of packets as they arrive. 3.SA An SA is a set of security parameters used by a tunnel for authentication and encryption.Key management tunnels use one SA for both directions of traffic;data management tunnels use at least one SA for each direction of traffic.Each endpoint assigns a unique identifier,called a security parameter index(SPI),to each SA. A set of SAs is needed for a protected data pipe,one per direction per protocol.For example,if you have a pipe that supports Encapsulating Security Protocol(ESP) between peers,one ESP SA is required for each direction.SAs are unquirely identified by destination(IPSec endpoint) address,security protocol(AH or ESP),and SPI. Note the following regarding SAs: --IP Security(IPSec) SAs are unidirectional and are unique in each security protocol. --An Internet Key Exchange(IKE) SA is used by IKE only,and unlike the IPSec SA,it is bidirectional(双向的). --IKE negotiates and established SAs on behalf of IPSec. --A user can also establish IPSec SAs manually. 4.AH(Authentication Header) and ESP(Encapsulating Security Payload) note: AH is used to provide data integrity and authentication.It does not provide any form of encryption to the payload of the packet.AH uses a keyed one-way hash function(also call an HMAC) such as MD5 or SHA-1 to guarantee the integrity and origin of the packet.Optionally,it can provide anti-replay protection. ESP is primaryily used to provide payload encryption.With the current revision of the RFC for ESP,it also includes the ability to provide authentication and integrity. Because ESP can do all the services needed in a secure VPN network(includeing optional Ahs services),most implementations do not include any AH options.When the IPSec standed was created,its developers took into account the need for increased security. Therefor,IPSec can use different algorithms for payload encryption,such as DES to give you 56-bit encryption or 3DES to give you 168-bit encryption.As the need for stronger payload encryption arises,the standard will allow vendors to implement other algorithms. |