Re: [IPsec] Large Scale VPN

[Praveen Sathyanarayan <[e-mail]>]

I would like to re-iterate again.

1.) Juniper solution is not based on GRE. Juniper solution is based on
"pure" IPSec in tunnel mode. It works very well.
2.) Juniper implementation has many proprietary messages to solve all
scenarios. NHRP is required, but it is not complete.
3.) Authentication method to authenticate spokes can be proprietary.

We believe there is a need for standard, so that different vendors can
interop.

-- Praveen


On 12/21/11 5:16 PM, "Mike Sullenberger" <[e-mail]> wrote:

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                         |
| [e-mail]                .:|:.:|:.         |
| Customer Advocacy              CISCO           |
+------------------------------------------------+



+------------------------------------------------+
| Mike Sullenberger; DSE                         |
| [e-mail]                .:|:.:|:.         |
| Customer Advocacy              CISCO           |
+------------------------------------------------+
_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec