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

From: Gregory Lebovitz <[email-masked]>
Date: Wed, 26 Feb 2003 09:37:30 -0800

within...

> -----Original Message-----
> From: Stephane Beaulieu [mailto:[email-masked]]
> Sent: Wednesday, February 26, 2003 8:53 AM
> To: Theodore Ts'o; Gregory Lebovitz
> Cc: [email-masked]; [email-masked]
> Subject: RE: Configuration portion of OPEN ISSUES...
> 
--SNIP--
> 
> Some of us had agreed that a good path forward would be to keep the
> configuration payload for initial very basic configuration 
> (IP, WINS, DNS,
> DHCP-SERVER-IP).  This would satisfy a VERY LARGE number of existing
> deployments (100% that I've seen so far, though I'm not naive 
> enough to
> think that it won't change ;).  It would also allow you to 
> use a RADIUS or
> LDAP server in the back-end (rather than DHCP). 

We have probably understated how important it is to the installed base to be
able to use RADIUS and LDAP for client configuration backend server. Most of
my organziation's large enterprise and xSP customers use RADIUS today, not
DHCP for client configuration. That is why so many of us implementors are in
consensus about the solution I and Stephane are describing: it would offer
the network operators the most flexibility to leverage their current
configuration infrastructure, be it DHCP, RADIUS or LDAP. 

> *IF* other 
> DHCP specific
> information is required, a remote Client MAY send a DHCP 
> packet (via a valid
> IPsec SA) directly to the DHCP server to get the rest of the 
> configuration.
> 
> I *thought* this was the agreement, but somewhere along the way, this
> changed to
> 
> > > 	* Keep configuration payload and allow optional
> > > 		RFC 3456-style configuration
> 
> Nobody wants to do this because this basically says you need 
> to support both
> CP and RFC3456.
> 
> Where it should have said
> 
> *Keep configuration payload and allow optional unicast DHCP 
> configuration
> after phase 1 is complete.

Or maybe:
 * Keep configuration payload, and show (possibly in Appendix or another
document) how it works with various backend config servers, i.e. DHCP,
RADIUS, LDAP.

BTW, Darren Dukes and I are working right now on some text for this. Stay
tuned.
 
> I *think* everyone can live with this.  Some have expressed a 
> desire for
> other solutions (DHCP in IKE for example), but I have not 
> heard anyone say
> that the above solution is not acceptable.

This is the consensus I thought we had reached.

Gregory.

---

From: Van Aken Dirk <[email-masked]>
Date: Fri, 28 Feb 2003 09:45:18 +0100

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: [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: Van Aken Dirk <[email-masked]>
Date: Fri, 28 Feb 2003 10:33:38 +0100

Hi Folks,

See my comments inline.

><trimmed> 
> For the record, I did not suggest DHCP-over-IKE, and I think Tero,
> Derek, and Tylor did (and maybe Pekka too). There were a number of
> others as well, including Gregory Lebovitz and Michael Richardson. For
> my part, I suggested that it should be *discussed* as one possible
> alternative, and I am glad to see that the discussion has not been
> summarily abbreviated. 
> 
> Arguably, one of the reasons we are still discussing remote access
> issues after 4 years of bickering is that the discussion 
> process has not
> truly been open. Directives have come down from the AD's and/or the wg
> chairs without adequate open discussion of the issues and 
> alternatives.
> Remote access has been treated as an unwanted stepchild of ipsec, when
> in fact, it is one to the primary commercial deployment scenarios for
> ipsec today.

Same opinion! I'm active in the DSL router space and due the fact that DSL
is unlocking bandwidth at a very cheap price/fee we see central office LAN's
constantly expanding via WAN DSL links and a churn from expensive leased
lines towards DSL. IPSec complements this move as it provides for security.
Of course some people will again say this is out of the ipsra scope ...

> 
> Everyone here who has been participating must agree that at 
> some times,
> some topics have been off-limits - and it is not clear that this has
> been appropriate. We will only reach an agreement (which may 
> turn out to
> be one that is distasteful in equal parts for all concerned) if the
> process is open. Clearly it must be a bounded discussion in terms of
> time, but it must be had in full regardless of its impact upon
> artificial deadlines. Even though we all want to get this 
> behind us asap
> and move on, the discussion will never finally be closed until we all
> agree that all realistic approaches have been fairly evaluated.

Correct ! The discussion on RFC3456 proves this point: some people seemed
not familiar with DHCP so how can one discuss a proposal as one does not
understand the basic architecture. Of course the same applies to me: I'm not
that familiar with IPSec ;-) ...

Dirk

> 
> > One of the frustrating things about trying to determine consensus in
> > the IPSEC wg is that the consensus seems to change from 
> week to week,
> > perhaps (in part) because some wg contributors are not reading this
> > mailing list regularly.
> 
> I think a few of us have flip-flopped or otherwise 
> significantly altered
> our positions in the last month (or at least, I know that I have). For
> my part, it has been largely due to running out of energy, 
> and tiring of
> the squabbling after so many years. I still have strong opinions about
> how little need there is to impact ipsec/ike with remote access
> configuration, but I am clearly in the minority, and in the 
> interest of
> forward progress, I have demonstrated my willingness to acknowledge my
> fallibility, and to compromise and move forward. I would hope others
> would do the same, and that the comment above is not intended to
> criticize those who might do so.
> 
> Scott
>

---

From: "Jing Xiang" <[email-masked]>
Date: Fri, 28 Feb 2003 11:57:44 -0500

I am afraid my previous post was unsuccessful. (I apologize if you've seen
it twice)

I would also like to argue we go with 1) or Derek's interpretation of 3) on
the basis that
*)Configuration Payload satisfies  the basic needs(IP address, DNS, WINS)
*)Most install base I am aware of uses ldap or RADIUS not DHCP as address
server

Regards!
/Jing
Jing Xiang, [email-masked]
Nortel  Networks
Contivity Engineering

-----Original Message-----
From: Derek Atkins [mailto:[email-masked]]
Sent: Wednesday, February 26, 2003 2:13 PM
To: Tylor Allison
Cc: Van Aken Dirk; 'Gregory Lebovitz'; 'Theodore Ts'o';
[email-masked]; [email-masked]
Subject: Re: Configuration portion of OPEN ISSUES...

Tylor Allison <[email-masked]> writes:

> > To clarify this open issue can we modify the list as follows (in order
to
> 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

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