Hן Mike
On Dec 22, 2011, at 3:16 AM, Mike Sullenberger 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.
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.
>
> 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.
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.
> 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.
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"
> 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.
I think otherwise, regardless of the specific technology.
> 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 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
>
> 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 |
> | m...@cisco.com .:|:.:|:. |
> | Customer Advocacy CISCO |
> +------------------------------------------------+
>
>
>
> +------------------------------------------------+
> | Mike Sullenberger; DSE |
> | m...@cisco.com .:|:.:|:. |
> | Customer Advocacy CISCO |
> +------------------------------------------------+
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
