Lancom Systems LCOS 3.50 Manuel D’Utilisation
Chapter 14: Virtual Private Networks—VPN
LANCOM Reference Manual LCOS 3.50
335
V
irt
ua
l Pri
vat
e Ne
two
rks—
VP
N
Generation of the authentication data
In the second step, AH generates a new hash code using the checksum and a
key, the final authentication data. A variety of standards are available under
IPSec for this process as well. LANCOM VPN supports HMAC (Hash-based
Message Authentication Code). The hash functions MD5 and SHA-1 are
available as hash algorithms. The HMAC versions are accordingly known as
HMAC-MD5-96 and HMAC-SHA-1-96.
key, the final authentication data. A variety of standards are available under
IPSec for this process as well. LANCOM VPN supports HMAC (Hash-based
Message Authentication Code). The hash functions MD5 and SHA-1 are
available as hash algorithms. The HMAC versions are accordingly known as
HMAC-MD5-96 and HMAC-SHA-1-96.
This clarifies why AH leaves the packet itself unencrypted. Only the checksum
of the packet and the local key are added to the packet together with the ICV,
the authentication data, in encrypted form as a verification criterion.
of the packet and the local key are added to the packet together with the ICV,
the authentication data, in encrypted form as a verification criterion.
Replay protection – protection against replayed packets
In addition to the ICV, AH assigns a unique sequence number to each packet.
The recipient can thus recognize which packets were intercepted by a third
party and resent. Attacks of this type are known as “packet replay“.
The recipient can thus recognize which packets were intercepted by a third
party and resent. Attacks of this type are known as “packet replay“.
AH does not cater for the masking of IPSec tunnels unless additional
measures, such as NAT-Traversal or an outer Layer-2-Tunneling (e.g.
PPPT/L2TP), are used that offer “changeable” IP headers.
measures, such as NAT-Traversal or an outer Layer-2-Tunneling (e.g.
PPPT/L2TP), are used that offer “changeable” IP headers.
14.8.5
Key management – IKE
The Internet Key Exchange Protocol (IKE) permits the integration of
subprotocols for managing the SAs and for key administration.
subprotocols for managing the SAs and for key administration.
Within IKE, two subprotocols are used in LANCOM VPN: Oakley for the
authentication of partners and key administration, and ISAKMP for managing
the SAs.
authentication of partners and key administration, and ISAKMP for managing
the SAs.
Setting up the SAs with ISAKMP/Oakley
Establishing an SA involves a sequence of steps (with dynamic Internet
connections, these steps follow the exchange of the public IP addresses):
connections, these steps follow the exchange of the public IP addresses):
햲
The initiator sends a plain-text message to the remote station via ISAKMP
with the request to set up an SA and with proposals for the security
parameters of the SA.
with the request to set up an SA and with proposals for the security
parameters of the SA.
햳
The remote station replies with the acceptance of a proposal.
햴
Both devices now generate key pairs, each consisting of a public and
private key, for Diffie-Hellman encryption.
private key, for Diffie-Hellman encryption.