RE: Configuration portion of OPEN ISSUES...

[Van Aken Dirk <Dirk.VanAken@thomson.net>]

Hi Tylor,

See my comments below.

> >
> > 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.


Initially, I started the "DHCP vs IKEModeCfg" discussion with following
proposal:

Specify in IKEv2 either of:

*) Configuration payload
*) RFC3456-style configuration

At that time I was also in favour of only one mechanism) however this choice
was too aggressive so I changed my opnion into:

*) Keep configuration payload and allow OPTIONAL RFC 3456-style
configuration

I could even live with the MUST keyword for IKEModeCfg and the MAY keyword
for RFC3456-style.

And yes I agree with you that to be interoperable a vendor has to implement
both. On the other hand due to advantages of one method over the other only
one method would become popular (i.e. let the best win ...).


It seems that today there are now 4 proposals on the table. I list them
below with prefixed +/- indicators. 

1) Keep configuration payload
++ implemented for IKEv1 (although there are still many IPSec
implementations are out there without IKEModeCfg)
-- limited in functionality compared to DHCP

In the assumption that a stand-alone DHCP server will be used for address
assignment 1) has following negative points:
-- how to couple the IKEModeCfg & IKE state machine to a DHCP
Client/Server's state machine ?
-- how to match IKEModeCfg payloads with DHCP payloads ?

2) Remove configuration payload and pursue RFC 3456-style configuration
-- IKEModeCfg implementers have to start all over again. However better to
decide on it now; within a few years it is too late.
++ assuming the solution is based on the construct
DHCPclient-DHCPRelay-DHCPServer it inherits all the properties of what is
possible in non-VPN LANs today
++ simplicity (of course if one is familiar with the DHCP architecture)
-- scalable in the sense that multiple VPN clients can request IP
configurations

3) Keep configuration payload and allow optional RFC 3456-style
configuration
Same remarks as 1) and 2)

4) Remove configuration payload and pursue an DHCP-over-IKE style
configuration
++ it removes the limitations that IKEModeCfg has
++ depending on how IKEModeCfg is implemented it might require less rework.
i.e. If IKEModeCfg is implemented as follows:
IKEMoceCFG-DHCPClient-DHCPServer, implementing DHCP-over-IKE merely comes
down to reformatting IKE messages
-- it has a similar limitation as 1): the IKE state machine is completely
different from that of a DHCP client

To conclude: I prefer 3) and have mixed feelings about 4).

Best regards - Dirk

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


----------------------------------------------------------- 
As of February 12, 2003 Thomson unifies its email addresses on a worldwide
basis.Please note my new email address: dirk.vanaken@thomson.net 

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