7
IPsec VPN
118
An
SA
is
unidirectional
and
relates
to
traffic
flow
in
one
direction
only.
For
the
bidirectional
traffic
that
is
usually
found
in
a
VPN,
more
than
one
SA
is
required
per
connection.
Typically,
when
only
ESP
or
AH
is
used,
two
SAs
will
be
created
for
each
connection,
one
describing
the
incoming
traffic,
and
the
other
the
outgoing.
When
ESP
and
AH
are
used
in
conjunction,
four
SAs
will
be
created.
IKE proposals
An
IKE
algorithm
proposal
list
is
a
suggestion
of
how
to
protect
IPsec
data
flows.
The
VPN
device
initiating
an
IPsec
connection
will
send
a
list
of
the
algorithms
combinations
it
supports
for
protecting
the
connection.
It
is
then
up
to
the
device
at
the
other
end
of
the
connection
to
say
which
proposal
is
acceptable.
The
responding
VPN
device,
upon
receiving
the
list
of
supported
algorithms,
will
choose
the
algorithm
combination
that
best
matches
its
own
security
policies,
and
reply
by
specifying
which
member
of
the
list
it
has
chosen.
If
no
mutually
acceptable
proposal
can
be
found,
the
responder
will
reply
by
saying
that
nothing
on
the
list
was
acceptable,
and
possibly
also
provide
a
textual
explanation
for
diagnostic
purposes.
This
negotiation
to
find
a
mutually
acceptable
algorithm
combination
is
done
not
just
to
find
the
best
way
to
protect
the
IPsec
connection
but
also
to
find
the
best
way
to
protect
the
IKE
negotiation
itself.
Algorithm
proposal
lists
also
contain
other
IKE
related
parameters.
Further
details
of
the
IKE
negotiation
and
the
other
IKE
parameters
are
described
next.
IKE negotiation
An
IKE
negotiation
consists
of
two
phases:
•
IKE
Phase
1:
Negotiate
how
IKE
should
be
protected.
•
IKE
Phase
2:
Negotiate
how
IPsec
should
be
protected.
These
phases
are
described
in
detail
next.
IKE phase 1: IKE security negotiation
An
IKE
negotiation
is
performed
in
two
phases.
The
first
phase,
phase
1,
is
used
to
authenticate
the
two
VPN
gateways
or
VPN
clients
to
each
other,
by
confirming
that
the
remote
device
has
a
matching
pre
‐
shared
key.
Since
publishing
details
of
the
negotiation
in
plain
text
is
undesirable,
IKE
first
agrees
upon
a
way
of
protecting
the
majority
of
the
IKE
negotiation.
This
is
done
by
the
initiator
sending
a
proposal
list
to
the
responder.
After
the
responder
accepts
one
of
the
proposals,
the
initiator
authenticates
the
other
end
of
the
VPN
to
make
sure
the
responder
is
who
it
claims
to
be,
as
well
as
proves
to
the
remote
device
that
initiator
is
who
is
claims
to
be.
Next,
a
technique
known
as
a
Diffie
Hellman
Key
Exchange
is
used
to
initially
agree
to
a
shared
secret
between
the
two
parties
in
the
negotiation
and
to
derive
keys
for
encryption.
