Subject: Re: [IPsec] AD VPN: protocol selection

From: Jean-Francois Dive <[email-masked]>
Date: Tue, 10 Dec 2013 15:50:22 +0100

Hello ipsec-me,

I wanted to chip in as i am following up the debates on this list on
the direction the working group is going for. My personal interest
comes from the vendor side (ipsec/ike implementation in previous jobs)
as well as deployment and design (user side). Full disclosure: i work
for Cisco but very far away from product development/standardization,
i therefore speak for myself.

I think draft-detienne-dmvpn-00 should be the basis for
standardization work. My main arguments are:

-> clear layer separation: this project in fact create a layer 2
resolution protocol for NBMA networks, i don't see why this should sit
within a protocols that is made for key distribution and peer
authentication (and possibly security policy distribution, see next
point).

-> policy enforcement and distribution should not be a main driver for
ipsec/ike: today's requirements for security requires deep inspections
and all sort of other services (policy mgmt, enforcement and
distribution) to be ran across a vpn tunnel, we should focus on just
that: the tunnels.

-> the more the solution will be self contained in ike the more
proprietary extensions will show in the field so that vendors can add
their own features, this could affect interoperability.

-> topology discovery and reachability management are 2 different
things and i believe this proposal's goal is focused on dynamic
topology discovery and establishment. Routing protocols solves
reachability management if required (redundancy, fast convergence).

-> it can be deployed with today's ike / ipsec implementations (for
expl no kernel change in linux).

-> it does not require specific support for any non ipv4|6 unicast
protocols that could be ran on top of the tunnels (mpls / network
virtualization, mcast,  etc..).

-> sitting outside of ike means it can ran without it over ipsec with
manual keying. I know a lot of people disregard this but this means
this could be applied to other type of environment (military ipsec for
expl) which relies on physical keys.

-> Scalability / multi-hubs are taken into account.

thanks,

regards

J.

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 10 Dec 2013 23:45:03 +0200

Dear AD VPN authors, friends, relatives and colleagues,

Please do not turn this selection process into a lobbying effort. The 
chairs are trying to determine consensus, and this requires reasoned 
opinions from as many of the group's participants as possible, with 
emphasis on our regular contributors. What this is not is a vote.

Jean-Francois, this mail is not aimed personally at you, and I look 
forward to have you contribute to this list. I am trying to make a 
general point here, based on my understanding of IETF process rules.

Now back to our regular program: we have had several useful responses on 
this thread so far, but still too few to determine the group's 
consensus. Please keep those responses coming!

Thanks,
	Yaron

---

From: Jean-Francois Dive <[email-masked]>
Date: Tue, 10 Dec 2013 23:00:15 +0100

well yaron, i still stand on what i mentioned on the list. I truely
didnt saw my email as a cisco trying to defend cisco type of email but
something i personally thought (naively as i see) would be food for
brain more than food for market battle.

On Tue, Dec 10, 2013 at 10:45 PM, Yaron Sheffer <[email-masked]> wrote:
> Please do not turn this selection process into a lobbying effort. The chairs
> are trying to determine consensus, and this requires reasoned opinions from
> as many of the group's participants as possible, with emphasis on our
> regular contributors. What this is not is a vote.
>
> Jean-Francois, this mail is not aimed personally at you, and I look forward
> to have you contribute to this list. I am trying to make a general point
> here, based on my understanding of IETF process rules.
>
> this thread so far, but still too few to determine the group's consensus.
> Please keep those responses coming!
>
> Thanks,
>         Yaron