[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on draft-ietf-ipsec-dhcp-01.txt
Following is a (probably not comprehensive) list of initial comments:
- the current draft only deals with configuring the internal sgw
interface; however, this mechanism could be extended in a
straightforward manner to include one or more hosts behind the sgw,
especially if the sgw is a bump-in-the-wire encryptor protecting one
host, but also in other cases.
- item 2 in section section 2.2 says the dhcp sa should be deleted after
the internal interface is configured since later dhcp traffic will be
carried over the vpn tunnel. This presumes that a tunnel will be
established which will permit (perhaps other things) dhcp traffic. Since
protocol is a valid filtering criteria, this presumption may be
incorrect. Perhaps this text should be somehow qualified (or removed).
- section 2.3, item 1 suggests that some client ID (besides the MAC) be
placed in the chaddr field of the dhcp message. The text goes on to say
that this field is not interpreted by gateway or dhcp server. However,
existing dhcp implementations may use the MAC from this field to select
the appropriate config parameters from the dhcp database. The suggested
mechanism would require that the client ID be used by the dhcp server
for this purpose, rather than the MAC. Perhaps some additional language
noting this would be in order, or perhaps this requirement should be
dropped, and the client hardware address (MAC) should remain untouched.
- section 2.3, item 2 designates a short lifetime for the dhcp sa, and
says that all future dhcp communication should use the vpn sa. For the
reasons noted earlier, this language should be modified.
I do agree that the initial SA should be dhcp-only, but not that it
needs to be immediately dropped. I think some sort of wildcard needs to
be used in the client ID for IKE so that subsequent DHCP operations for
either the internal interface or another internal host will succeed. I
will concede that this may not be in keeping with a given installation's
security policy, and hence, should be configurable.
I would also point out that there are other DHCP config operations which
may occur using this (or another dhcp) SA, including all of those
suggested in isakmp-mode-cfg.
Scott
References: