Paul to answer but
IKE is a key exchange process so both ends agree
IPSEC has two SA one to receive and one to send. It can be the same number but they are really two seperate things.
Bidirectional, simply means that a single SA is agreed upon and used to send and receive to the remote peer. The IKE SA is simply a "channel" not tunnel (no IPsec encap. type). The IPsec SA must be unidirectional (each peer has 2 SAs with separate keying material), 1 SA to send and 1 SA to recieve from the remote peer. HTH
Let me clarify the difference between: channel versus tunnel. The IKE SA, by definition, requires ISAKMP, which uses UDP 500. In other words, while the DH-session key is used to encrypt the last ISAKMP Main Mode message(peer authentication in ISAKMP), there is no additional L3/IP/parallel-layer encapsulation performed in ISAKMP negotiation. IPsec, by definition, employs ESP or AH to encapsulate an L3 packet; which results in a true tunnel. A tunnel is simply an additional encapsulation at the same layer. A secure tunnel (VPN) will also employ encryption to obfuscate/hide the data. HTH
what type of informtion you send or recieve after IKE SA agreement from both peers
i may can understand that when IKE SA is matched so it is the only one SA used (for example the same preshared key is used for encryption and decryption ) whether it is sending(encrypting) or recieving (decrypting )
this is explains how this could be bidirectional
and if we are taking about IPsec SA
so if one transfrom set is matched between two IPsec peer
the transform set will be only applied in one direction
i mean if we for example use encryption & authentication through ESP(WHICH IS MAY AES 256)
so we are going to encrypt the traffic that matching the traffic defined in Crypto ACL (sourced from from local peer detined to remote peer)
so if i am recieving encrypted traffic from remote peer (regarding one direction )am i going to decrypt it using the IPSEC SA (matched transform set)
really i am so confused
Taking your question to the extreme.
You do not need ISAKMP and you do not need to encrypt the data.
crypto ipsec transform-set T1 esp-null esp-sha-hmac
set session-key inbound esp 300 authenticator 9999888877776666555544443333222211110000
In the above example we are using AH rather than ESP and you can see the SA we will use is 300. The Other party could use any number including 300.
So all ISAKMP starting with a known or public key is to generate a symetric key to be used by both parties but you do not need to use ISAKMP if you use static keys for AH or ESP.
Conwyn is absolutely correct; ISAKMP does not have to be used. However, with static keys the VPN is considered less secure, because the keying material doesn't dynamically change during a session or for any session, unless manually changed by administrator. We like our keys to change, to thwart possible brute force, MitM, known ciphertext and plaintext attacks.