RE: OPEN ISSUES WG LAST CALL: draft-ietf-ipsec-ikev2-05.txt

["Yoav Nir" <ynir@CheckPoint.com>]

Seems that only a week ago there was a wide-spread agreement on using the
configuration payload as it is in -05, with the client later completing any
missing data using tunneled DHCP informs.  This would mean that the security
gateway would not have to know the DHCP protocol.

Both RFC 3456 and the dhcp-over-ike drafts make sense only if IP addresses
are allocated by a DHCP server.  Of the two, I prefer the dhcp-over-ike
draft, but I still see some drawbacks:

- If the gateway has an internal pool or if it obtains the addresses from a
RADIUS server, it will have to translate the requests and replies from and
to DHCP format.  DHCP format is not simple and contains many irrelevant
fields.  Even if allocation is done using a DHCP server, the gateway will
need to learn to be a DHCP relay agent.  The configuration payload is much
simpler.

- DHCP packets are large (over 300 bytes) and unbounded in size.  The IKE
packets are already large enough to cause trouble occasionally.  We don't
need this extra baggage.  Configuration payloads are small by comparison.

- DHCP tunneling in IKE requires at least 4 packets, 6 if the client makes
an attempt to obtain a previous address.  This will make the IKE negotiation
go to 6 or 8 packets as opposed to 4 in -05.

I am in favor of the first option: use CP to pass IP address, subnet mask
and DHCP server address (optionally also NBNS, DNS) and optionally use DHCP
inform for all the rest.

Yoav Nir



  -----Original Message-----
  Subject: OPEN ISSUES WG LAST CALL: draft-ietf-ipsec-ikev2-05.txt
  <snip>

  For example, in the case of the open issue on how to handle
  configuration, the choices to the working group are:

	* Keep configuration payload
	* Remove configuration payload and pursue RFC 3456-style configuration
	* Keep configuration payload and allow optional
		RFC 3456-style configuration

=========================================================================
The content of this message may contain private views and opinions which do
not constitute a formal disclosure or commitment.