Subject: [IPsec] Stopping work on Auto-Discovery VPN

From: Yaron Sheffer <[email-masked]>
Date: Fri, 23 May 2014 20:22:41 +0300

Dear WG members,

After being unable to reach consensus on a protocol that solves the AD 
VPN problem, we set up a smaller group to discuss the solutions on the 
table and try to reach agreement between the competing proposals. 
Unfortunately, this approach was similarly unsuccessful even after 
multiple phone calls with the respective authors.

As a result, the chairs have decided to officially withdraw this work 
item from the group's agenda. We will work with the ADs to remove it 
from our charter.

We would like to thank the authors of RFC 7018 (Auto-Discovery VPN 
Problem Statement and Requirements), and encourage the authors of the 
protocol proposals to publish them for the benefit of the community.

Regards,

     Paul and Yaron

---

From: Yoav Nir <[email-masked]>
Date: Mon, 26 May 2014 10:34:32 +0300

On May 23, 2014, at 8:22 PM, Yaron Sheffer <[email-masked]> wrote:

> Dear WG members,
> 
> After being unable to reach consensus on a protocol that solves the AD VPN problem, we set up a smaller group to discuss the solutions on the table and try to reach agreement between the competing proposals. Unfortunately, this approach was similarly unsuccessful even after multiple phone calls with the respective authors.
> 
> As a result, the chairs have decided to officially withdraw this work item from the group's agenda. We will work with the ADs to remove it from our charter.
> 
> We would like to thank the authors of RFC 7018 (Auto-Discovery VPN Problem Statement and Requirements), and encourage the authors of the protocol proposals to publish them for the benefit of the community.
> 
> Regards,
> 
>    Paul and Yaron

FWIW, I think this is the wrong decision. Both the working group and apparently the market have shown a desire for a dynamic, large-scale VPN, and we have enough people willing to do work on a solution.

Yes, there are some designs floating around and some implementations at various levels of maturity, and there was a lot of controversy. Not coming up with a single, standard design will lead to multiple non-interoperable implementations, a fragmented market, and vendor lock-in, which runs contrary to the mission of the IETF to make the Internet better. Implementers will be forced to either “choose sides” or worse, implement more than one design, and lacking a standard document, much of the actual protocol will be either vendor-specific or reverse-engineered. 

This is exactly the kind of bad outcome that standards bodies are supposed to prevent, and I don’t believe that admitting defeat is the right decision here.

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 May 2014 10:36:14 -0400

Yoav Nir <[email-masked]> wrote:
    > FWIW, I think this is the wrong decision. Both the working group and
    > apparently the market have shown a desire for a dynamic, large-scale
    > VPN, and we have enough people willing to do work on a solution.

    > Yes, there are some designs floating around and some implementations at
    > various levels of maturity, and there was a lot of controversy. Not
    > coming up with a single, standard design will lead to multiple
    > non-interoperable implementations, a fragmented market, and vendor
    > lock-in, which runs contrary to the mission of the IETF to make the
    > Internet better. Implementers will be forced to either “choose sides”
    > or worse, implement more than one design, and lacking a standard
    > document, much of the actual protocol will be either vendor-specific or
    > reverse-engineered.

I think that the chairs were underwelmed by the number of comments and the
amount of review that the proposals got.  Yes, I know that you, and I and
Tero had opinions, but that was pretty much it.

My impression is that the people who *want* a solution to this are not
satisfied unless certain *critical* parties agree to come to the table.  As
such, going forward with any standard which does not include those
parties takes a lot of effort, and, yet results in the same bad situation
that you mention.

I would rather one design.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Yoav Nir <[email-masked]>
Date: Mon, 26 May 2014 21:41:41 +0300

> Tero had opinions, but that was pretty much it.

There were a few others: Steve Kent, Brian Weis, Andreas Steffen, and Paul Wouters, plus some people who hadn’t participated in the WG before.

Those who are draft authors (about 10 of us all told) were told to stay out of the discussion.

> I would rather one design.

One is better than three. One is also much better than zero.

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Mon, 26 May 2014 15:00:55 -0400 (EDT)

> One is better than three. One is also much better than zero.

Then, and now even more, I've become more afraid of bells and whistles
and kitchen sinks in IKEv2. There is already a lot of criticism that
IKE/IPsec is too much "designed by committee". I am not sure if we are
served well by one spec that has features of all three proposals. On top
of that, it seemed this work was mostly driven by allowing less
specified policies to "fix themselves" into more specified. And I
haven't been convinced these solutions are at the right layer.

We are definitely adding more features than we can obsolete :/ Perhaps
our parents should tell us to get rid of some of our old barely toys
before we can ask for new ones :P

Paul

---

From: Yoav Nir <[email-masked]>
Date: Mon, 26 May 2014 22:42:01 +0300

> before we can ask for new ones :P

Can we trade in AH and IKEv1’s “new group mode” for a dynamic policy?  I’ll throw in transport mode, if needed.

Yoav