If the end system is behind a NAT, then there is no way for another end system to address a packet to this end system. Not only is opportunistic encryption impossible, but it is also impossible for any communication to be initiated to the end system. It may be possible for this end system to initiate such communication, but the initiator in this use case is the mobile user. Note that the private IP address of a host in an end system behind a NAT may also change due to the fact that it is migrated for load balancing or other reasons.
Mike ----- Original Message ----- From: Yoav Nir To: 'Michael Ko' ; ipsec@ietf.org Sent: Tuesday, November 08, 2011 4:14 PM Subject: RE: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement In that case, would RFC 4322 solve your problem? It is based on DNS. -------------------------------------------------------------------------------- From: Michael Ko [mailto:mich...@huaweisymantec.com] Sent: 08 November 2011 03:54 To: Yoav Nir; ipsec@ietf.org 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 To: Michael Ko ; ipsec@ietf.org 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" <mich...@huaweisymantec.com> 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 ----- 发件人: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] 代表 Yoav Nir 发送时间: 2011年10月14日 13:24 收件人: ipsec@ietf.org 主题: [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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -------------------------------------------------------------------------------- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
