[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Modefg considered harmful



Hi Scott,

we at the Zurich University of Applied Sciences have implemented
DHCP-over-IPsec (RFC 3456) as an add-on for Linux FreeS/WAN last
summer and this convenient feature is now being widely used by many
people. From our own VPN production system at the university we have
gained practical experience in everyday use.

If you don't allow split-tunneling for remote VPN clients then I
must agree with you that a special DHCP SA for getting a Virtual IP
address won't be needed since the subnet mask will be 0.0.0.0/0 anyway.

But in all other cases where the remote client is allowed to access
the Internet locally (e.g. via NAT) and just maintains one or several
IPsec tunnels to specific subnets, you must setup a short-lived DHCP
SA restricted to 0.0.0.0:udp/68 because the DHCPDISCOVER broadcast message
carries a destination IP of 255.255.255.255 but you wouldn't want to
tunnel all IP traffic over this SA.

Regards

Andreas

Scott G. Kelly wrote:
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

====================================================================== Andreas Steffen e-mail: andreas.steffen@xxxxxxxx Zuercher Hochschule Winterthur home: http://www.zhwin.ch/~sna/ CH-8401 Winterthur (Switzerland) phone: +41 52 267 76 77 ===============================================================[ZHW]==