[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Moving forward with IKE V2: A proposal for final edits to ikev2-04
Here are my thoughts on the 2 issues:
1. On the modecfg vs DHCP - I prefer modecfg. We have used it for years
without issue. It is easy to implement and understand, it is
self-contained,
it does not require additional SAs and is easily extensible. Not only have
we
added many modecfg attributes to solve customer issues in the past but we
have
been able to easily coordinate the new attributes with RADIUS via vendor
specific
attributes for a complete solution. Adding LDAP to this proxy scheme has
also been
very easy.
How easy would it be to implement a "complete" solution via DHCP. It seems
to me that
we would have 2 options with DHCP. We either pass DHCP through to a DHCP
server and make
it transparent to IKE/IPsec, or we intercept the DHCP request and proxy it
to RADIUS or
LDAP. In my opinion, the former option is not really an option. We can not
use DHCP servers
for anything other than IP address assignment. If we told our customers
that they need to
set up user-based configuration attributes on their DHCP server, they would
quickly throw
us out. The latter option (proxy) would work but is more difficult to
implement than modecfg.
The difficulty comes with the loose coupling to user tunnels and the
additional SA.
2. I find Paul's naming convention very confusing (maybe it is because I am
not up on the latest PKIX requirements). I like the old naming convention
because they are core names and not abstractions of names. By this I mean
that a core name can be used in several different scenarios (if all the
scenarios have the same ID requirement) as long as the core ID requirement
is well
documented. The abstractions, at least to me, may be more intuitive, but
could cause an ID explosion as more and more abstractions are introduced.
The worst case is that many abstract IDs really map to the same core ID.
What I would really like to see is a decrease in the number of IDS. It
would be nice to cover all the bases with 2 or 3 IDs and properly document
the
use of the IDs.
Victor
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derrell Piper
> Sent: Wednesday, February 05, 2003 6:46 PM
> To: Theodore Ts'o
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Moving forward with IKE V2: A proposal for final edits to
> ikev2-04
>
>
> For purposes of consensus, here's my take on the two topics that Ted
> and Barbara have asked for comments on. A friend once
> remarked to me,
> "Go not to the elves for advice for they will say both 'yes' and
> 'no'..."
>
> RE: revised identity
>
> First, I sympathize with Cheryl and Scott in that we've been avoiding
> the larger problem from the start and it has continued to
> plague us at
> interoperability workshops. The lack of consideration for proper PKI
> integration is one of IKEv1's biggest omissions, that's
> clear. And yet
> here we are several years down the road and we still haven't
> been able
> to do anything about it. So, is now the right time and place to deal
> with it? Perhaps, but only if there were very strong
> consensus amongst
> existing vendors.
>
> I think revisions to the IKE ID specifications will be needed at some
> time in the future. The existing ID definitions are vague and ad hoc
> and yet we've still managed to garner a fair amount of
> interoperability
> despite it all. It hasn't necessarily been pleasant or easy,
> but over
> time most IKE implementations now do interoperate.
>
> Would the proposed identity revisions make things so much better that
> it would clear up some large majority of PKI interoperability
> problems?
> I don't think so. I think most of the problems are due somewhat to
> the inherent complexity of certificate-based PKI
> interoperability and,
> moreover, to the lack of a defined PKI profile for IKE. I happen to
> think there's more value in defining a PKI profile, such as the one
> described in, draft-ietf-ipsec-pki-profile-01.txt. We don't need
> revised identities to do that. It seems similarly clear that revised
> identities would bring with them a new and entirely different set of
> interoperability issues.
>
> I have concerns that the management paradigm for many vendors is very
> closely tied to the existing IKE identity types, so wholesale
> revision
> in this area might well represent a serious headache for many
> vendors.
> The impact of the protocol changes is largely transparent and
> the other
> revisions ought to mostly present themselves as elimination of
> unnecessary configuration options. Deleting things is
> relative easy.
> But I can see how wholesale identity revision might seriously impact
> much of the existing management software, end-user documentation, and
> vendor regression testing. I think we do need to be concerned about
> fielded implementations.
>
> From an implementation standpoint, I also worry about combining
> something like identity revision with all the other IKEv2 changes.
> You'd essentially be starting from scratch at the next bake-off. Now
> I'm not going to claim lots and lots of code reuse between IKEv1 and
> IKEv2, yet there is some overlap. But if you completely rototill the
> identity processing on top of this, you're very close to
> starting from
> scratch. Anyone who lived through those early bake-off's would not
> want to go back there. Well, except for Big Al's BBQ Shack,
> perhaps.
> :-)
>
> Finally, if we're taking our deadline seriously, I don't think we're
> anywhere near consensus on what a revised identity proposal entails.
> Given the traffic just this week, there are many suggestions beyond
> what was originally discussed on the list last fall. Are
> there simple
> PKIX mappings? Are there simpler alternatives? IMHO, it's unlikely
> we're going to agree on such fundamental changes to identity
> representation in the next week. I think we should keep working on
> this as we should keep working on the PKI profile. But these
> items can
> occur orthogonally to IKEv2.
>
> In summary, our strategy of ignoring this has worked so well in the
> past that I recommend we continue it a while longer.
>
> RE: configuration mode vs. dhcp relay
>
> I'm on the fence with this one. I see good arguments for both
> approaches: there are simplicity arguments for MODECFG and there are
> richness arguments for DHCP. FWIW, the implementation I previously
> worked on was much closer to MODECFG.
>
> I'd welcome proposed text that explicitly shows the IKEv2 changes to
> support RFC3456. If we had that we could make a reasonable choice
> between the two. But absent that, I think we should pursue
> what we've
> got now and be willing to revisit this issue in the future.
>
> It's not an option to do nothing. IKEv2 needs a defined mechanism to
> dole out internal addresses to remote clients and MODECFG has been
> written up for IKEv2 and shown to work in IKEv1. IKEv2 is not viable
> without remote client support.
>
> Regards,
>
> Derrell
>
> On Thursday, January 30, 2003, at 02:57 PM, Theodore Ts'o wrote:
>
> > If you feel otherwise, please speak now.
> >
> > A) Revised identity
> > --------------------
> >
> > Paul Hoffman has a proposal,
> draft-ietf-ipsec-revised-identity-00.txt,
> > which radically changes how identities are handled.
> Specifically, it
> > would eliminate the ID payload with the following types:
> >
> > ID_IPV4_ADDR 1
> > ID_FQDN 2
> > ID_RFC822_ADDR 3
> > ID_IPV6_ADDR 5
> > ID_DER_ASN1_DN 9
> > ID_DER_ASN1_GN 10
> > ID_KEY_ID 11
> >
> > et.al, and replaces it with a FullID payload with the
> following types:
> >
> > 1 PKIX certificate
> > 2 Certificate bundle
> > 3 Hash-and-URL of PKIX certificate
> > 4 URL to a PKIX certificate bundle
> > 5 PKIX keyIdentifier
> > 6 IDForSharedSecret
> >
> > This would be fundamental change in the management and
> administraton of
> > IPSEC and IKE, so is not something to adopt lightly, and without a
> > clear
> > consensus of the working group. This was discussed in two
> threads on
> > the IPSEC mailing list: one starting on November 5th (subject Adding
> > revised identities to IKEv2), and one starting on December 8th
> > (subject:
> > Summary of revised identity changes). People who spoke in
> favor on the
> > mailing list included Francis Dupont and Bill Sommerfeld, with
> > qualified
> > support from Michael Richardson (if support for bare keys
> is added) and
> > Tero Kivinen (who is concerned about the complexity of the
> proposal).
> >
> > This proposal was discussed in Atlanta, but Charlie,
> Barbara, and Ted
> > were left with the impression that there was not consensus
> among those
> > who met to discuss legacy authentication after the IPSEC wg
> meeting to
> > pursue adoption of Paul's proposed change. Paul believes otherwise.
> > Since it is the job of working group chairs to determine
> consensus, we
> > (Barbara and Ted) hereby ask that those who believe we
> should pursue
> > the
> > revised identity proposal to please speak up.
> >
> > It should be noted that there are some intermediate positions beyond
> > what is currently in draft-ietf-ipsec-ikev2-04.txt and the
> > revised-identies draft. For example, we could add the Hash-and-URL
> > type
> > to the Certificate payload, if the goal is shrink the size of IKE
> > messages (with the tradeoff of increasing complexity in IKE
> > implementations). We could also add a CERT hash type to the ID
> > payload, without nuking the traditional FQDN or IPv4/6 addresses
> > identity mechanisms (although again, by adding new types,
> we would be
> > increasing the complexity of the specification and implementations).
> >
> > Due the relatively small number of people who have spoken
> in favor of
> > this proposal or its less-radical alternates, the default choice for
> > IKEv2 has to be what is currently in ikev2-04. So those
> who believe we
> > should make this change (or those who strongly believe we
> should not)
> > are requested to speak up now, or forever hold your peace....
> >
> >
> > B) DHCP-based vs. MODECFG style remote access configuration
> > -----------------------------------------------------------
> >
> > Currently, draft-ietf-ipsec-ikev2-04.txt handles remote access via a
> > Configuration payload with defined attributes. An
> alternate mechanism
> > involves using tunneled DHCP requests. The latter approach
> is about to
> > be published as an RFC by the IPSRA working group.
> Proponents of this
> > method argue that it is more powerful than modecfg (because of the
> > extensibility and large number of options already specified
> for DHCP;
> > for example, being able to specify DNS, time, print, or
> WINS servers,
> > and so on.) It is also argued that it requires less code on the
> > server/firewall, since an existing DHCP server can be used.
> >
> > Proponents of the modecfg approach argue that many implementation
> > already have support for modecfg, and that setting up sort-lived
> > specialized tunnels to allow the DHCP packets to flow through the
> > gateway is kludgy, and requires multiple special case entries into
> > packet forwarding tables. Modecfg proponents also argue that it is
> > also
> > possible to transform modecfg requests into DHCP requests,
> so there are
> > implementation choices that do not require reimplementation of the
> > DHCP's address assignment function. They also point out that it
> > certainly is possible --- and in some ways easier --- to obtain the
> > time, print, WINS server information by using DHCP (via the
> DHCPINFORM
> > request) after the IPSEC tunnel is setup and the client address is
> > assigned.
> >
> > Either approach seems to be workable. It is certainly true
> that most
> > of
> > the people in Atlanta were implementors who were already
> familiar with
> > modecfg, representing a large implementation community. That being
> > said, there is also some number of working group members that are in
> > favor of an approach similar to draft-ietf-ipsec-dhcp-13,
> including Van
> > Aken Dirk, Michael Richardson, and Scott G. Kelley. One way or
> > another, however we need to make a choice and move forward.
> >
> > Given that we have a fully specified solution in the
> ikev2-04 draft,
> > and
> > it would seem that while there is a sizeable minority in
> favor of the
> > ipsec-dhcp-13 approach, the majority are comfortable with
> the modecfg
> > based approach. So at this point, we, as working group
> chairs, judge
> > that the consensus is with the current approach.
> >
> > If there are those who feel otherwise, or who see fatal
> problems with
> > the current approach, please speak now.
>