Subject: Re: [IPsec] Large Scale VPN

From: Mike Sullenberger <[email-masked]>
Date: Wed, 21 Dec 2011 17:16:14 -0800 (PST)

Everyone,

I noticed that in the four vendor presentations in the "P2P VPN - side
meeting" in TAIPEI that none of vendors chose to extend or augment IKE/IPsec
to solve this class of problems.  This is not to say that vendors haven't
chosen to extend IKE/IPsec to solve other classes of issues, I.e. XAuth and
Mode-config.

My firm belief is that IKE/IPsec is at the wrong level to solve or
standardize the creation of encrypted dynamic mesh networks.  DMVPN, as one
example, has for over 8 years solved this issue by using protocols that are
specifically designed for the different needs for creating encrypted dynamic
mesh networks.  If you modify IKE/IPsec to perform these functions then you
will end up having to add (redo) the functionality of already existing
protocols in IKE/IPsec and the result will not be able to do as "good" a
job.

   1. I have no problem with creating a problem statment including use
      cases, but I am not sure how usefull this will be coming from the
      ipsecME WG when the solution for the problem statement shouldn't
      be done in IKE/IPsec.

   2. I don't see how nor why the ipsecME WG should be involved in vendors
      publishing an informational RFCs about their solutions. I didn't think
      that there is a need for a WG's approval or help to publish an
      informational RFC.

      Note, we (Cisco) have said that we are willing to submit an
      informational RFC about DMVPN and having it ready by August 2012 is
      fine.

   3. Again I firmly believe that a standardized solution to encrypted
      dynamic mesh networks should not be done by modifying IKE/IPsec.
      Therefore the ipsecME WG is the not the right IETF WG to analyze and
      or select a solution.

   4. At least three vendors (Cisco, Juniper and Alcatel) have very
      successfully implemented large-scale encrypted dynamic mesh networks
      by using IKE/IPsec for encryption, GRE for protocol independent
      tunneling, NHRP for endpoint discovery and Routing protocols (even
      static routing) for the routing/forwarding of data traffic (subnets)
      through the encrypted tunnels.

I therefore vote against this change to the ipsecME WG charter.

-1

Thanks,

Mike Sullenberger

>If we want Paul and Yaron to take this to our AD, we need to show
>that there are more people who think these work items are a good
>idea. More people than just me and MCR.  So please show your
>support (or objections!) soon. An "I think this is a good idea",
>"I think we should use ternary logic", or "+1" is all it takes.
>
>Yoav
>
>On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote:
>>
>> Agree. How about:
>>
>> In an environment with many IPsec gateways and remote clients that
>> share an established trust infrastructure (in a single
>> administrative domain or across multiple domains), customers want
>> to get on-demand point-to-point IPsec capability for efficiency.
>> However, this cannot be feasibly accomplished only with today's
>> IPsec and IKE due to problems with address lookup, reachability,
>> policy configuration, etc.
>>
>> The IPsecME working group will handle this large scale VPN problem
>> by delivering the following:
>>
>> * The working group will create a problem statement document
>>   including use cases, definitions and proper requirements for
>>   discovery and updates. This document would be solution-agnostic.
>>   Should reach WG last call around October 2012.
>>
>> * The working group will review and help publish Informational
>>   documents describing current vendor proprietary solutions.
>>   These should be ready for IETF last call by August 2012.
>>
>> * The working group will choose a common solution for the
>>   discovery and update problems that will satisfy the
>>   requirements in the problem statement document. The working
>>   group may standardize one of the vendor solutions, a
>>   combination, an superset of such a solution, or a new
>>   protocol.
>>
>>

+------------------------------------------------+
| Mike Sullenberger; DSE                         |
| [email-masked]                .:|:.:|:.         |
| Customer Advocacy              CISCO           |
+------------------------------------------------+

+------------------------------------------------+
| Mike Sullenberger; DSE                         |
| [email-masked]                .:|:.:|:.         |
| Customer Advocacy              CISCO           |
+------------------------------------------------+

---

From: Yoav Nir <[email-masked]>
Date: Thu, 22 Dec 2011 14:59:59 +0200

Hן Mike

> protocols in IKE/IPsec and the result will not be able to do as "good" a

I believe that IPsec tunnels work very well. The current standards lack two things:
 1. The ability to discover how to get to some address (what is the next gateway
    to which I should establish a tunnel
 2. The ability to establish trust between two gateways. It's not enough to find 
    an IP address for the "next hop", you also need to learn how to authenticate 
    it.

Routing protocols can do #1 on real networks. Running them on tunnels seems to
be like using links as metaphors for tunnels. But that's just my bias.
They don't do much for #2 unless you extend them, and then you might as well 
extend any other protocol.

>      ipsecME WG when the solution for the problem statement shouldn't

I think the solution is for the IPsecME group regardless of whether it is in IKE, in a web service, or in a combination of mGRE, NHRP and OSPF. This is about building large scale IPsec VPNs, and that's the job of the IPsecME group, even if it involves extending a routing protocol.

>      informational RFC about DMVPN and having it ready by August 2012 is

The term I used was "review and help publish". It's going to be an Informational document describing an existing technology. Of course the WG has no input on the technical issues in DMVPN. The comments you'll be able to get from the group are along the lines of "section #3 is not clear", or "could you rephrase section 2.3 in RFC 4301 terminology?", not "let's change the encoding here to XML"

>      Therefore the ipsecME WG is the not the right IETF WG to analyze and

I think otherwise, regardless of the specific technology.

>      through the encrypted tunnels.

I seem to remember from the Juniper presentation that they did not use GRE (except as a Cisco compatibility feature - Check Point has that too). No idea about Alcatel
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.