Hi Michael,
Michael Richardson wrote:
<trimmed...>
I still do not understand why creating a ephemeral IPsec SA to carry the
DHCP traffic makes sense. I don't see that it is any easier for
bump-in-the-stack implementations, nor do I see it easier for in-stack
implementations.
This is probably a point of confusion for some, and is what originally
resulted in a change that some folks have referred to as "kludgy", that
being the on-the-fly modification of the selectors you can do to after
dhcp to avoid the second sa negotiation.
We should back up a bit, as there is something really fundamental that
should be called out. Not all ipsec users have the same security
requirements, so ideally, the mechanisms we design should be adaptable
to varying levels of security, depending upon one's needs.
In the case at hand, it is not always *necessary* that the precise
selectors be known in advance of phase 2. In some cases, we may be
willing to trust both tunnel endpoints to behave, and in such cases a
phase 2 can be negotiated with zero'd traffic selectors prior to DHCP,
and this SA can be used for all traffic. In such cases, it is not
necessary to have a separate SA for DHCP, and it is not necessary to do
anything "kludgy" if you want to avoid this. It is only in the cases
where security requirements are such that the SGW is not able/willing to
trust the IRAC, and therefore requires more stringent address controls,
in which the ephemeral DH SA (or some hack to get around it) is
required.
Scott