[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
MODECFG Implementers POV needed [FW: IKE V2 discussion on ipsec mailing list --- implementers POV wanted]
Your opinions, pro-modecfg or con, in IKEv2 are greatly appreciated. The
four individuals discussing this on the ipsec working group list are not
enough to give the chairs an idea of what the consensus is.
Thanks,
Darren
> -----Original Message-----
> From: Theodore Ts'o [mailto:tytso@xxxxxxx]
> Sent: Tuesday, February 04, 2003 8:06 PM
> To: IPSEC implementors
> Subject: IKE V2 discussion on ipsec mailing list --- implementors POV
> wanted
>
>
> Hi there,
>
> You're getting this message because the IPSEC working group
> needs to make some final decisions about the shape of IKEv2 if we are to
> meet the February 15th deadline which our Area Director has challenged
> us with. There are a number of issues which are on the table, and while
> there has been some discussion by a few people on the IPSEC mailing
> list, there were many implementors who have not commented on these
> items. So Barbara and I pulled together a list of implementors from an
> interop workshop plus people who had expressed interested on the secure
> legacy authentication, and we are sending this note to you to urge your
> participation on the IPSEC wg list.
>
> After all, it is the duty of working group chairs to determine
> consensus, and it is hard to do that if many people haven't been
> participating on the mailing list. (For example, there is anecdotal
> story going around that a number of implementors were unhappy about the
> decision to use cipher suites, for reasons unspecified. Because no one
> spoke up against cipher suites, we have ended up going with them, for
> better or for worse. There are other issues coming up which are far
> more critical, and so we very much want your comments either in favor or
> against these proposals.)
>
> Some of the key issues under discussion include the following:
>
> 1) MODECFG vs. DHCP (RFC 3456 style)
>
> At the Atlanta IETF meeting, a number of implementors gathered together
> after the IPSEC meeting to discuss secure legacy authentication. At the
> time, there was a clear preference towards using a MODECFG-style
> approach. Such an approach has been included into ikev2-04, although it
> is integrated into the main part of the IKEv2 exchange.
>
> However, there has since been extension discussion on the IPSEC mailing
> list from those who advocate using an approach similar to RFC 3456,
> which entails setting up a special DHCP SA. It is clearly a more
> powerful approach, but it can entail more complexity.
>
> It seems strange that none of the modeconfig proponents have spoken up.
> Have people examined what is currently specified in
> draft-ietf-ipsec-ikev2-04?
> If so, please express your opinions on it, either pro or con.
>
> If it turns out that Barbara and I, when we meet to determine wg
> consensus in the future, see that all of the recent working group
> discussion has been in favor of an DHCP/RFC-3456 style approach, and no
> one has spoken in favor of the Configuration payload approach specified
> in ikev2-04, so based on the apparent wg consensus, we give instructions
> to Charlie to rip out the Configuration payload and replace it with text
> derived from RFC 3456 --- I really, really don't want to hear later that
> a bunch of implementors are doing a slow burn because the working group
> ignored their concerns.....
>
> 2) Revised Identity
>
> Paul Hoffman has a proposal which would replace the current methods of
> identifying initiators and responders (i.e.):
>
> 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
>
> with a completely different set of 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 represents a fundamental shift in how IPSEC implementations handle
> identities. It has potential effects on how policies are looked up, and
> how access control is handled. It may effect user interfaces,
> documentation, and training in very fundamental ways. (After all,
> naming has always been considered the ultimate computer science rathole
> for this very reason.)
>
> Hence, Barbara and I are very concerned that this proposal has attracted
> very little comment, either pro or con. There are a few people who have
> expressed support, but not all that many people. I did receive a
> private comment from an implementor who said in reference to Paul's
> revised-identity proposal, "the amount of change this would inflict on
> existing IKE implementations scares the bejeezus out of me".
> Unfortunately, he has declined my invitation (nay, strong encouragement)
> to make this observation on the public ipsec wg mailing list.
>
> To be fair, there are some arguments in favor of this proposal; by
> forcing all implementations to use certificates as the basis of their
> naming, it can solve a number of interoperability concerns. (Although
> on the other hand, the pki-profile document also solves many of these
> issues without resorting to using an entirely new naming system.)
>
> ------------------
>
> For more details, please see my e-mail to the IPSEC mailing list on
> January 30th, with the subject line "Moving forward with IKEV2: A
> proposal for final edits to ikev2-04", and subsequent comments. Also
> please see the thread started by Benard Aboba, entitled "modecfg
> considered harmful". Please also look at the latest ikev2 and
> revised-identity I-D's.
>
> If you haven't commented because you think you agree with the way you
> think things are going, please speak up and say that you've read
> ikev2-04, and that you like it. (Or what you don't like about it and
> which you believe should change.)
>
> If you haven't commented because you haven't had time to keep up with
> the list, and some of the more recent I-D's, I strongly encourage you to
> take the time to look at draft-ietf-ipsec-ikev2-04.txt, and look at some
> of the more recent e-mail exchanges on the list.
>
> I personally have my own personal biases towards how I believe some of
> these issues are settled from a purely technical perspective, but with
> my working group chair hat on, the most important thing at this point is
> that the *are* settled definitively, one way or another. The bottom
> line is that we need your comments, from as many points of view as
> possible. So what you have to say is important.
>
> Many thanks,
>
> Ted and Barbara
> IPSEC wg chairs
>