Re: Configuration portion of OPEN ISSUES...

[Derek Atkins <derek@ihtfp.com>]

Tylor Allison <allison@securecomputing.com> writes:

> > To clarify this open issue can we modify the list as follows (in order to
> > not have any confusion on what we are discussing about):
> >
> > 1) Keep configuration payload
> > 2) Remove configuration payload and pursue RFC 3456-style configuration
> > 3) Keep configuration payload and allow optional RFC 3456-style
> > configuration
> > 4) Remove configuration payload and pursue an DHCP-over-IKE style
> > configuration
> >
> > I'm in favour of 2) and can live with 3).
> >
> > Dirk
> 
> I agree with this distinction in the options...
> 
> I'd prefer to see option 1 or 4... don't really care which one.  I strongly
> disagree with option 3... leaving this optional really means implementing
> both if you want to be interoperable with all vendors.

I think option 3 needs to be clarified some before it's written off
completely.  My reading of option 3 is that you use the config payload
for the IP Address, netmask, and a few, limited other options, and
then optionally the client can use DHCP to obtain _other_
configuration informtation.  Perhaps we need a "3a" and "3b" to define
the different interpretations of what you have in option 3?

If my interpretation of #3 is "correct", then I have no problem with
it, because it does not affect the IPsec/IKE implementation at all.
It's just a hook on the client to run the DHCP client once you're up
on the net.  The (standalone) DHCP client can perform further
configuration (beyond IP Address leases, which you get from the config
payload).

Personally I don't have a strong opinion between 1, my interpretation
of 3, and 4.  I would lean towards 1 or my interpretation of 3, only
because DHCP is larger and less bounded, so it would be nice to know
we can complete the configuration process in 2 messages (via config)
rather than 4-6 additional messages (via encapsulated DHCP).  Size and
latency do matter, to some extent.  I think that all of it is dwarfed
by RSA/DH operations, but the number of round trips does matter.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       derek@ihtfp.com             www.ihtfp.com