Re: Configuration portion of OPEN ISSUES...

[Tylor Allison <allison@xxxxxxxxxxxxxxxxxxx>]

On 26 Feb 2003, Derek Atkins wrote:

> Tylor Allison <allison@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx             www.ihtfp.com

Yep, I agree that even further clarification is needed for option 3, as my
read on it was exactly opposite of yours.  I was pretty much lumping your
interpretation of option 3 in with option 1.

I'll step back from what I stated before... I'd prefer to see the MC as is
(with optional client use of DHCP to retrieve other config options)... the
reason I was entertaining DHCP-over-IKE was that it was an option that I
felt I could live with, and at the time it was offered, it wasn't clear to
me that any consensus had been made.  I was thinking perhaps more people
would prefer on DHCP-over-IKE vs. MC as is... it looks like this is not the
case.

=====================================================================
= Tylor Allison         Secure Computing Corporation        =========
=====================================================================