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