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

From: Gregory Lebovitz <[email-masked]>
Date: Tue, 25 Feb 2003 15:02:40 -0800

> -----Original Message-----
> From: Theodore Ts'o [mailto:[email-masked]]
> Sent: Tuesday, February 25, 2003 11:46 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: OPEN ISSUES WG LAST CALL: draft-ietf-ipsec-ikev2-05.txt
> 
--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.

---

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 26 Feb 2003 10:47:05 -0500

On Tue, Feb 25, 2003 at 03:02:40PM -0800, Gregory Lebovitz wrote:
> are working on text to clarify it. 

I THOUGHT we had some consensus for that as well, but right after
Barbara and I gave Charlie editing directions for ikev2-05, and
several days after I conclusion of the comment period for how to
resolve these issues, a number of implementors, including Tero, Derek,
Tylor Allison, argued against this position.  And others, including
Scott Kelly and Pekka Riikonen, suggested a DHCP-over-IKE.  (Sorry for
not including it in our original list.)  And none of the people in
favor of keeping configuration payload spoke up.

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.

Another frustration is that some people will suggest an idea, such as
DHCP over IKE, but not necessarily propose specific text to implement
such an idea.

So, I hereby call upon:

1) People who are in favor of DHCP-over-IKE to submit proposed text
that explicit documents their proposal

2) People who are in favor of keeping configuration payload to speak
up.  And more generally, people with any opinion on any of the options
to speak up, listing the tradeoffs to the various options and
explaining why they prefer one option over another.

						- Ted

P.S.  The following very amusing "version" of RFC 2418 Section 6 was
written by Jari Arkko as part of a discussion on the I-D
draft-hardie-wg-stuckees-00.txt.  For the humor impaired, this was a
joke, but in all seriousness, we could really use more "stuckees" in
this working group.  (We're almost done, folks; it just requires one
last hard push to finish the ikev2 document.)

And now, for your reading pleasure...

6.1. PHB (Pointy Haired Boss)

   The PHB is concerned with making forward progress through a
   fair and open process, and has wide discretion in the
   conduct of WG business. The PHB must ensure that a number
   of tasks are performed, either directly or by others
   assigned to the tasks. Unlike their corporate counterparts,
   however, IETF PHBs do not actually have authority to
   command specific persons to perform specific tasks.

6.2. Slave

   Most IETF working groups focus their efforts on a document,
   or set of documents. A working group generally designates a
   person or persons to serve as the Slave or Slaves for a
   particular document. The Slave is responsible for ensuring
   that the contents of the document accurately reflect the
   decisions that have been made by the working group. Until
   very recently, Slaves also had to carry all the water to the
   IETF hotel, dig holes in the ground using their bare hands,
   and edit their documents using nroff.

6.3. Stuckee

   In order to make progress, working groups need to establish
   an understanding of technical alternatives, evaluate the
   feasibility of the proposed solutions in a variety of
   environments, and carefully review their documents.
   Furthermore, consensus is more fun when there are more
   participants than just the PHBs and the Slaves. Stuckees are
   expected to participate in the discussions, perform timely
   reviews of documents, and express their opinions when
   decisions are being made.

   Like others, Stuckees are volunteers. However, Stuckees do
   not get their name in any of the publications.

6.4. Tourist

   Most IETF working group meetings are held in big rooms.
   Experience has shown that the number of Slaves and Stuckees
   rarely exceeds ten for any working group. This would look bad
   for any potential observers trying to gauge the interest
   level of the new technology. In order to solve this problem,
   working groups arrange for a number of designated Tourists to
   participate the meetings. By definition, all other
   participants other than the PHBs, Slaves, Stuckees, and Area
   Dictators are Tourists. It is inappropriate for a Tourist to
   participate in discussions, whether live or on the list.

   Tourists are volunteers as well, but they get free Internet
   access while in the room.

6.5. Area Dictator

   Area Dictators are responsible for ensuring that working
   groups in their area produce coherent, coordinated,
   architecturally consistent and timely output as a
   contribution to the overall results of the
   IETF. Additionally, given that Slaves are often illiterate
   and Stuckees lazy, the Area Dictators have formed the
   Internet Engineers Spelling Group (IESG), which helps the
   working groups to correct the grammar mistakes from their
   documents.

;-)

---

From: "Stephane Beaulieu" <[email-masked]>
Date: Wed, 26 Feb 2003 11:53:13 -0500

> perhaps (in part) because some wg contributors are not reading this

Sometimes, the same question gets asked over and over and over.... and it
gets tiring of restating your opinions over and over and over...  Not a
personal dig here Ted, just a fact of life in the IETF.

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

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

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.

---

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 26 Feb 2003 10:40:43 -0800

Comments below...

> favor of keeping configuration payload spoke up.

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. 

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.

> perhaps (in part) because some wg contributors are not reading this

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: Bill Sommerfeld <[email-masked]>
Date: Wed, 26 Feb 2003 15:43:24 -0500

> that the above solution is not acceptable.

You should have heard people (including myself) say that any
configuration scheme within IKE should reuse as much of DHCP syntax
and option codes as possible rather than defining a wholly new
parameter space.

							- Bill

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Feb 2003 18:12:59 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Bill" == Bill Sommerfeld <[email-masked]> writes:
    >> *Keep configuration payload and allow optional unicast DHCP
    >> configuration after phase 1 is complete.
    >> 
    >> 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.

    Bill> You should have heard people (including myself) say that any
    Bill> configuration scheme within IKE should reuse as much of DHCP syntax
    Bill> and option codes as possible rather than defining a wholly new
    Bill> parameter space.

  I want to emphasis that just because one says "DHCP-over-IKE", that
does not mean that such a system has to talk to a DHCP server. Decoding
DHCP messages is no more difficult than radius, PPP or IKEv2. (Maybe
a lot easier than IKEv1)

  You can implement the relevant pieces in the gateway. DHCP vs modecfg
can be just about syntax.

  I will fill the state machine changes, and suggest text for dhcp-over-ike,
but I won't bother if there is no interest.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: "Yoav Nir" <[email-masked]>
Date: Thu, 27 Feb 2003 12:06:47 +0200

Seems like we're converging again... :-)

It is about syntax, but there are disadvantages to using DHCP.  Decoding
DHCP messages is not difficult.  One problem with it is that DHCP packets
are considerably longer than Config payloads.  With all the payloads we
already have, it is always a good idea to reduce the size of the packets.

I am in favor of Config Payloads as they are specified in -05 and as
implemented by some vendors.  Further configuration using DHCP is OK, if
needed, but does not affect the IKE protocol.

Yoav Nir

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Michael Richardson
Subject: Re: Configuration portion of OPEN ISSUES...

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls
[
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device
driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security
guy"); [

============================================================================
==============
The opinions expressed here are my own and do not necessarily reflect those
of my employer

---

From: "Darren Dukes" <[email-masked]>
Date: Thu, 27 Feb 2003 20:54:45 -0500

I'll speak up with my preference for the Configuration Payload and
DHCPINFORM.  Pros/cons to come after the CP to dhcp/radius/ldap doc is done.

Darren

> [mailto:[email-masked]]On Behalf Of Theodore Ts'o
> Sent: Wednesday, February 26, 2003 10:47 AM
> To: Gregory Lebovitz
> Cc: [email-masked]; [email-masked]