Re: Modefg considered harmful

[Andreas Steffen <andreas.steffen@zhwin.ch>]

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@zhwin.ch
Zuercher Hochschule Winterthur      home:   http://www.zhwin.ch/~sna/
CH-8401 Winterthur (Switzerland)    phone:  +41 52 267 76 77
===============================================================[ZHW]==