In that case, would RFC 4322 solve your problem? It is based on DNS. ________________________________ From: Michael Ko [mailto:[email protected]] Sent: 08 November 2011 03:54 To: Yoav Nir; [email protected] Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement
Yoav, Thank you for taking the time to review the draft and providing your feedback. In the scenario depicted in my draft, there is pre-existing trust between the central repository and the other nodes. If I understand your draft correctly, it is akin to your center nodes which "introduce other nodes to each other, and it will also probably be about resolving differences in configuration and bypassing NAT". As envisioned, the central repository is not intended to be "specific to a small part of the Internet, say, a company or a government network", and most likely "the repository is some service that everybody can use, similar to DNS or the public CAs". But again, this is just a problem statement, not a solution proposal. The role of the central repository can evolve as we explore other alternatives and use cases. Mike ----- Original Message ----- From: Yoav Nir<mailto:[email protected]> To: Michael Ko<mailto:[email protected]> ; [email protected]<mailto:[email protected]> Sent: Tuesday, November 08, 2011 6:05 AM Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Hi Michael I have only skimmed your draft, and it does seem to have overlap with ours. However, I think your draft is more about generic hosts on the Internet that have no pre-existing trust between them. It's not clear whether this central repository that you mention in your draft is something specific to a small part of the Internet, say, a company or a government network, or if the repository is some service that everybody can use, similar to DNS or the public CAs. Our use-cases are when there is enough pre-existing trust to establish tunnels, just not all tunnels. It's mostly about turning stars or trees into meshes by having center nodes introduce other nodes to each other, and it will also probably be about resolving differences in configuration and bypassing NAT. That said, there is considerable overlap, and I hope you can be at our side meeting on Wednesday night. Yoav On 11/6/11 7:12 PM, "Michael Ko" <[email protected]<mailto:[email protected]>> wrote: I just came across this draft and there seem to be quite a bit of overlap in the problems to be solved between this draft and the draft I submitted last month titled "Problem Statement for Dynamic Secure Interconnect". Here is a link to the draft: http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 Dynamic Secure Interconnect examines the problems and challenges associated with the process of setting up secure interconnections between authorized network nodes. The network nodes can be located anywhere in a private or public network, directly connected or behind one or more levels of NAT. Setting up a secure interconnection in this environment entails the resolution of various issues such as authentication, peer discovery, virtual network address management, and connection parameters determination. I would be interested in getting together to discuss the problem associated with creating large scale mesh VPNs. Someone suggested Wednesday evening. That works for me. But I am open to other time slots as well. Mike ----- Original Message ----- 发件人: [email protected]<mailto:[email protected]> [mailto:[email protected]] 代表 Yoav Nir 发送时间: 2011年10月14日 13:24 收件人: [email protected]<mailto:[email protected]> 主题: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Hi all For years, one of the barriers to the adoption of IPsec was that configuration didn't scale. With thousands of peers, the PAD and SPD would become unwieldy, so even where IPsec was deployed it was often built in hub-and-spoke configurations, not because policy demanded this, but because it was more convenient to configure. Individual vendors have incompatible solutions for this, but they only work with that vendor's products, and within the same administrative domain. In this draft, we are proposing that the IPsecME working group take on a working item to first define the problem, and then offer solutions that will make IPsec scale better and in an inter-operable way. We plan to hold a side meeting in Taipei, and we welcome comments both before and at that meeting. Yoav http://www.ietf.org/id/draft-nir-ipsecme-p2p-00.txt http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00 _______________________________________________ IPsec mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ipsec ________________________________ _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
