Subject: [IPsec] AD VPN: protocol selection

From: Yaron Sheffer <[email-masked]>
Date: Tue, 03 Dec 2013 19:40:52 +0200

Dear IPsecME folks,

There is clear working group interest in a standard auto-discovery VPN 
solution. We have agreed-upon requirements [1]. And we have 3 serious 
contenders [2] [3] [4] for the solution. It is time to select a protocol 
to adopt into the working group.

We would like to ask people who are *not* authors on any of the solution 
drafts to send a short message to the list, saying which of the three 
they prefer, and a few reasons for their choice.

Please do *not* send mail saying which of the protocols you do *not* 
like - this would be far less useful. And please do not think up a new 
solution proposal, it's too late for that.

A quick process reminder: once we adopt a protocol, it becomes the 
starting point for the working group document. The WG can change the 
editor team and is free to make material changes to the protocol before 
it is published as RFC.

Thanks,
	Paul and Yaron

[1] http://tools.ietf.org/html/rfc7018
[2] http://tools.ietf.org/html/draft-mao-ipsecme-ad-vpn-protocol-02
[3] http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03
[4] http://tools.ietf.org/html/draft-detienne-dmvpn-00

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Dec 2013 15:49:49 -0500

I prefer draft-sathyanarayan-ipsecme-advpn.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 3 Dec 2013 12:53:45 -0800

> I prefer draft-sathyanarayan-ipsecme-advpn.

because.... ?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Dec 2013 17:11:37 -0500

I wrote: "I prefer draft-sathyanarayan-ipsecme-advpn."

Paul asked: " because.... ?"

Oh. 
I thought that I wasn't supposed to say why I didn't like other proposals :-) 

Okay... 

I prefer it because:
  1) it lives inside IKE.
  2) it deals with the question of distribution of authentication
     tokens.
  3) it requires no new kernel components, which means that it will
     run with *just* a modified IKE daemon on many mobile devices.
    Yes, you need root on Android and a jailbreak on iOS to run a modified
    IKE, but you don't need a new kernel, and all sorts of other host
    specific firmware blobs.  
    This means that while it might not be end-user-installable, if someone
    makes the patches, they can tested, and pushed easily into AOSP,
    and maybe Apple would accept them.

  4) it is very specific about what "routing" protocol would be the MTI
     ("IKE"/RFC4301!) , rather than being "well, whatever you like"

  5) it permits port-specific policies to be controlled by HQ.

-- 
]               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: Paul Hoffman <[email-masked]>
Date: Tue, 3 Dec 2013 16:16:21 -0800

> I thought that I wasn't supposed to say why I didn't like other proposals :-) 

Correct. We want to hear what anyone (among the non-authors) *likes* about particular proposals.

>  5) it permits port-specific policies to be controlled by HQ.

Thats the kind of list we are looking for. "It has feature X which I find useful / important."

--Paul Hoffman

---

From: Andreas Steffen <[email-masked]>
Date: Wed, 04 Dec 2013 09:59:47 +0100

Speaking for the strongSwan project, I'm favoring

   draft-sathyanarayan-ipsecme-advpn

because

   - The concept is simple but powerful and well embedded into the
      current IKEv2 message exchange architecture.

   - No overlay of additional routing protocols is needed.

   - The proposed solution has a lot of similarity with our
     Double-NAT IKEv2 Mediation Extension [1] that we proposed a
     couple of years ago and which has been implemented by strongSwan.
     Thus the integration of the draft-sathyanarayan-ipsecme-advpn
     capabilities into our architecture should be rather easy.
     In the future it might even be possible to extend the SHORTCUT
     exchange to Double-NAT situations.

   - The draft is in a very advanced state with all protocol details
     neatly worked out. It's ready for implementation, so we might
     give it a try :-)

Best regards

Andreas

[1] http://tools.ietf.org/html/draft-brunner-ikev2-mediation-00

======================================================================
Andreas Steffen                         [email-masked]
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Fri, 6 Dec 2013 16:03:53 +0000

Hi Yaron,

Is this an official poll or is it "just to see" ? If this is serious, what is the deadline ?

thanks,

	fred

On 03 Dec 2013, at 18:40, Yaron Sheffer <[email-masked]> wrote:

> Dear IPsecME folks,
> 
> There is clear working group interest in a standard auto-discovery VPN solution. We have agreed-upon requirements [1]. And we have 3 serious contenders [2] [3] [4] for the solution. It is time to select a protocol to adopt into the working group.
> 
> We would like to ask people who are *not* authors on any of the solution drafts to send a short message to the list, saying which of the three they prefer, and a few reasons for their choice.
> 
> Please do *not* send mail saying which of the protocols you do *not* like - this would be far less useful. And please do not think up a new solution proposal, it's too late for that.
> 
> A quick process reminder: once we adopt a protocol, it becomes the starting point for the working group document. The WG can change the editor team and is free to make material changes to the protocol before it is published as RFC.
> 
> Thanks,
> 	Paul and Yaron
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Fri, 6 Dec 2013 16:07:07 +0000

Hi Andreas,

On 04 Dec 2013, at 09:59, Andreas Steffen <[email-masked]> wrote:

> ...

please note that our proposal does not mandate a routing protocol. We also support IKEv2 config exchange and treat the protected subnets as "routes" for the tunnel.

Thanks!

	fred

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Dec 2013 08:42:44 -0800

On Dec 6, 2013, at 8:03 AM, Frederic Detienne (fdetienn) <[email-masked]> wrote:

> Is this an official poll or is it "just to see" ?

Both. That is, it is official in that the WG chairs asked for it, because we wanted "just to see". It is a poll, not a vote.

> If this is serious, what is the deadline ?

When we have enough input to get a sense of the WG. Given the meager response so far, we're not at all there yet.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Dec 2013 08:45:18 -0800

> please note that our proposal does not mandate a routing protocol. We also support IKEv2 config exchange and treat the protected subnets as "routes" for the tunnel.

And yet Yaron and I specifically asked:

> We would like to ask people who are *not* authors on any of the solution drafts to send a short message to the list, saying which of the three they prefer, and a few reasons for their choice.

Seriously, authors: please refrain. The WG has heard enough pitches from you for your proposals and, if not, you are free to update your drafts to make them clearer. This poll is to hear from the other people in the WG.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Fri, 6 Dec 2013 13:05:44 -0500 (EST)

On Tue, 3 Dec 2013, Yaron Sheffer wrote:

> solution.

> We have agreed-upon requirements [1].

I was unfortunately not really active during the requirements phase.

While I believe there is a need for auto-discovery without
preconfiguration, I do not think the current ideas of merging site-to-site
based VPNs using ADVPN proposals really increases security. It seems
a compromise for convenience at the expense of the intended security
of IPsec, and a continued trend from strict policy range based VPNs to
loose routing based VPNs, reducing IPsec to a virtual private untrusted
ethernet cable.

I think draft-sathyanarayan-ipsecme-advpn-03 comes closest to removing
any kind of routing decisions from the IKE/IPsec protocols, leaving the
IPsec subsystem as a consumer of the routing decisions made elsewhere.

Paul

---

From: Saurabh M <[email-masked]>
Date: Fri, 6 Dec 2013 13:01:43 -0800

Hi,
We'd prefer dmvpn( http://tools.ietf.org/html/draft-detienne-dmvpn-00) to
become the wg document.

The main reason for our recommendation are:

- It is what customers are asking for.

- We actually prefer that there are 2 separate protocols that co-operate to
build the complete solution as it gives us the flexibility for each one to
exist without mandating the other.

- It was fairly easy to build a solution using open-nhrp and strongswan.

Thanks

-Saurabh Mohan.

On Tue, Dec 3, 2013 at 9:40 AM, Yaron Sheffer <[email-masked]> wrote:

> contenders [2] [3] [4] for the solution. It is time to select a protocol to
> adopt into the working group.
>
> drafts to send a short message to the list, saying which of the three they
> prefer, and a few reasons for their choice.
>
> Please do *not* send mail saying which of the protocols you do *not* like
> - this would be far less useful. And please do not think up a new solution
> proposal, it's too late for that.
>
> starting point for the working group document. The WG can change the editor
> team and is free to make material changes to the protocol before it is
> published as RFC.
>
> Thanks,
>         Paul and Yaron
>

---

From: Yoav Nir <[email-masked]>
Date: Fri, 6 Dec 2013 23:25:42 +0200

[Changing the subject to avoid poisoning the protocol selection thread 
with my author-ness]

On 6/12/13 8:05 PM, Paul Wouters wrote:
> based VPNs using ADVPN proposals really increases security. 
They're not supposed to. They are supposed to increase efficiency and 
reliability. The problem we're trying to solve is that the way the 
standards and products work today, tunnels are configured one at a time. 
It's so labor-intensive, that administrators minimize the number of 
tunnels be defining hub-and-spoke topologies for any VPN that is large 
enough.

There is another problem that stems from the same state of standards and 
products - that IPsec is hardly ever used between administrative 
domains. Solving that would be great, and opportunistic encryption might 
be a start. Something with RPKI certificates could make it even better. 
But that is not the focus of this effort.
> It seems

I don't disagree, but defining the tunnels one at a time sounds more 
like SNA than TCP/IP.

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Dec 2013 13:05:24 -0500

> exist without mandating the other.

1) If you can can do this as it is, do we actually need to standardize
   anything?

2) if you can build this in a number of different ways, how will your
   customer interoperate with another similar solution, should they
   acquire (or be acquired) another entity that has a similar solution?

---

From: Timo Teras <[email-masked]>
Date: Mon, 9 Dec 2013 12:02:26 +0200

On Tue, 03 Dec 2013 19:40:52 +0200
Yaron Sheffer <[email-masked]> wrote:

> We would like to ask people who are *not* authors on any of the
> solution drafts to send a short message to the list, saying which of
> the three they prefer, and a few reasons for their choice.
> 
> editor team and is free to make material changes to the protocol
> before it is published as RFC.

My preference is on draft-detienne-dmvpn-00 to be used as a BASIS:

- The model is layered properly.

  - It does not try to make IKE a routing protocol, or SPD a full
    blown routing table.

  - Existing routing protocols can be used to setup active/backup
    gateway nodes or multipath routes for given prefix, as well as
    multicast routing (all these and more without additional IKE
    extensions)

- Dynamic routing of prefixes, allowing simpler and more flexible
  hub-to-hub configuration. 

- Multiple inter-operable implementations exists.

- Large installations exists, proving scalability.

Granted, the current draft misses still a lot of details. Especially
useful would be to have exact specification on how "thin" client can
work without routing protocols (e.g. mode config push of static
routes), how to setup NHS topology, what security measures are needed
to make sure nodes cannot impersonate someone else.

DMVPN properly addresses the complex requirement in RFC7018 2.2.
"[...] the routing implications of gateway-to-gateway communication
need to be addressed." which I think is one of the hardest issues here.

- Timo

PS. Please do not reply to this email. It merely reflects my personal
preference and opinion as requested. Non-authors can freely write in
reply to the original poll explaining why they like something else;
authors can freely update their drafts and publish them on separate
thread.

And yes, I have bias towards DMVPN having implemented parts of it.
But I believe similar bias exists when IKE implementers prefer doing
everything in IKE.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 09 Dec 2013 09:36:40 -0500

Saurabh,

> Hi,
> We'd prefer 
> dmvpn(http://tools.ietf.org/html/draft-detienne-dmvpn-00) to become 
> the wg document.
>
This statement may represent a lot of skew if the sample set if Cisco  
customers who are told this is an existing solution they can just enable 
:-).
>
> - We actually prefer that there are 2 separate protocols that 
> co-operate to build the complete solution as it gives us the 
> flexibility for each one to exist without mandating the other.
>
I worry that DMVPN allocates too much secruity-relevant contorl to the 
routing sub-system. Thus I prefer ADVPN.
> - It was fairly easy to build a solution using open-nhrp and strongswan.
I thought prior message exchanges indicated that the NHRP being used 
here included extensions not in the RFC.  I prefer choices based on 
compliance with existing RFCs, or explicitly-declared, new proposals.  
Hence, I prefer ADVPN.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Dec 2013 09:03:15 -0800

This time coming from the co-chair. We have not gotten enough interest from non-authors (or the folks who work for vendors sponsoring the proposals) to feel comfortable declaring consensus. We really want to hear from more of the hundreds of people on the mailing list before we declare consensus or give up at this late date.

=================================

Dear IPsecME folks,

Thanks,
	Paul and Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 18 Dec 2013 18:16:04 +0200

Hi,

To date we have had several good responses on this thread, but 
unfortunately not enough to gauge the group's consensus. So before you 
go on a well deserved vacation, please review the candidate protocols 
and let us know:

- Which one would you want as the starting point for an AD VPN RFC?
- What are your reasons?

Details and links in my original message: 
http://www.ietf.org/mail-archive/web/ipsec/current/msg08861.html

Thanks,
	Yaron