Which of the following is not a parameter that needs to be configured for the IKE security proposal? (Multiple choice)

Question

Options

• ANegotiation mode
• BAuthentication algorithm
• CEncryption algorithm
• DEncapsulation mode

• A
  6% (2)
• B
  84% (26)
• C
  10% (3)

Explanation

Authentication algorithm (B) and Encapsulation mode (D) belong to the IPsec SA (Phase 2) proposal, not the IKE security proposal. IKE's job is to establish a secure channel between peers, not to define how actual data traffic is wrapped or authenticated - those details are negotiated later in the IPsec phase.

Why A and C are wrong (they ARE IKE parameters): Negotiation mode (Main Mode vs. Aggressive Mode) controls how IKE Phase 1 exchanges occur, so it must be in the IKE proposal. Encryption algorithm (e.g., AES, 3DES) is needed to protect the IKE handshake messages themselves.

Why B is correct: The IKE proposal uses an authentication method (pre-shared key or digital certificates) to authenticate peers - "authentication algorithm" in this context refers to the data-integrity hash applied to IPsec traffic (AH/ESP), which belongs in the IPsec proposal.

Why D is correct: Encapsulation mode (Tunnel vs. Transport) determines how IP packets are wrapped for data transmission - this is an IPsec SA parameter, not an IKE SA parameter.

Memory tip: Think "IKE = handshake, IPsec = data." IKE only needs to know how to talk (negotiation mode) and how to hide that conversation (encryption). Anything describing how actual traffic is packaged or verified (encapsulation mode, authentication algorithm) lives in the IPsec proposal.

No community discussion yet for this question.