Subject: RE: Configuration portion of OPEN ISSUES...

From: Van Aken Dirk <[email-masked]>
Date: Wed, 26 Feb 2003 13:22:48 +0100

Hi Theodore, see my comment below.

> --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
> 
> If I'm reading your options correctly, we (I THINK) had some 
> consensus (or
> at least strong interest) on the list for the last option, 
> and some folks
> are working on text to clarify it. Did you mean to capture 
> with the last
> bullet the case where we use a ModeCFG-like format to run a 
> DHCP (or other)
> discovery/request in IKE? This would be very different than 
> "3456-style"
> configuration, as 3456 occurs in Phase2.
> 
> Just trying to clarify what you meant... thanks,
> 
> Gregory.
> 

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

----------------------------------------------------------- 
As of February 12, 2003 Thomson unifies its email addresses on a worldwide
basis.Please note my new email address: [email-masked] 

Thomson is the leader in solutions and technologies for the entertainment
and media industries and serves its customers under its four strategic
brands: Technicolor, Grass Valley, RCA and THOMSON. 
More about Thomson: http://www.thomson.net/videochain

---

From: Tylor Allison <[email-masked]>
Date: Wed, 26 Feb 2003 11:01:29 -0600 (CST)

> I'm in favour of 2) and can live with 3).

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.

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

---

From: Derek Atkins <[email-masked]>
Date: 26 Feb 2003 14:12:49 -0500

> 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
       [email-masked]             www.ihtfp.com

---

From: Tylor Allison <[email-masked]>
Date: Wed, 26 Feb 2003 16:11:55 -0600 (CST)

> by RSA/DH operations, but the number of round trips does matter.

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.