Setup guide

is looked up to decrypt it (using packet source, destination, security protocol and SPI value). If no
SA is found, the packet is dropped. If SA is found, packet is decrypted. Then decrypted packet's
fields are compared to policy rule that SA is linked to. If the packet does not match the policy rule it
is dropped. If the packet is decrypted fine (or authenticated fine) it is "received once more" - it goes
through dst-nat and routing (which finds out what to do - either forward or deliver locally) again.
Note that before forward and input firewall chains, a packet that was not decrypted on local host is
compared with SPD reversing its matching rules. If SPD requires encryption (there is valid SA
associated with matching SPD rule), the packet is dropped. This is called incoming policy check.
Internet Key Exchange
The Internet Key Exchange (IKE) is a protocol that provides authenticated keying material for
Internet Security Association and Key Management Protocol (ISAKMP) framework. There are
other key exchange schemes that work with ISAKMP, but IKE is the most widely used one.
Together they provide means for authentication of hosts and automatic management of security
associations (SA).
Most of the time IKE daemon is doing nothing. There are two possible situations when it is
activated:
• There is some traffic caught by a policy rule which needs to become encrypted or
authenticated, but the policy doesn't have any SAs. The policy notifies IKE daemon about that,
and IKE daemon initiates connection to remote host.
• IKE daemon responds to remote connection.
In both cases, peers establish connection and execute 2 phases:
• Phase 1 - The peers agree upon algorithms they will use in the following IKE messages and
authenticate. The keying material used to derive keys for all SAs and to protect following
ISAKMP exchanges between hosts is generated also.
• Phase 2 - The peers establish one or more SAs that will be used by IPsec to encrypt data. All
SAs established by IKE daemon will have lifetime values (either limiting time, after which SA
will become invalid, or amount of data that can be encrypted by this SA, or both).
There are two lifetime values - soft and hard. When SA reaches it's soft lifetime treshhold, the IKE
daemon receives a notice and starts another phase 2 exchange to replace this SA with fresh one. If
SA reaches hard lifetime, it is discarded.
IKE can optionally provide a Perfect Forward Secrecy (PFS), whish is a property of key exchanges,
that, in turn, means for IKE that compromising the long term phase 1 key will not allow to easily
gain access to all IPsec data that is protected by SAs established through this phase 1. It means an
additional keying material is generated for each phase 2.
Generation of keying material is computationally very expensive. Exempli gratia, the use of
modp8192 group can take several seconds even on very fast computer. It usually takes place once
per phase 1 exchange, which happens only once between any host pair and then is kept for long
time. PFS adds this expensive operation also to each phase 2 exchange.
Diffie-Hellman MODP Groups
Diffie-Hellman (DH) key exchange protocol allows two parties without any initial shared secret to
create one securely. The following Modular Exponential (MODP) Diffie-Hellman (also known as
"Oakley") Groups are supported:
Diffie-Hellman Group Modulus Reference
Group 1 768 bits RFC2409