Paul, It seems that my statement has been taken out of context. It is in response to the question from Yoav who asked "would RFC 4322 solve your problem". My response was paraphrased from section 6.3 of RFC 4322 on End System Behind a NAT/NAPT where it began with "If the end system is behind a NAT (perhaps SG-B), then there is, in fact, no way for another end system to address a packet to this end system."
The problem as stated in my draft addressed the situation where not all the attributes regarding the resources that a client wants to access is known. This include address, security protocol, configuration, etc. Having a center node to establish a line of trust between the client and the resources and to discover the attributes associated with the resources facilitate the process whereby a client can make a direct connection, most likely a secure tunnel, with the resource. For more information, please see my draft at http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 Mike ----- Original Message ----- From: Paul Wouters To: Michael Ko Cc: Yoav Nir ; [email protected] Sent: Sunday, November 13, 2011 2:54 AM Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement On Wed, 9 Nov 2011, Michael Ko wrote: > 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 neccessarilly true. If you look at traditional hosts, you are correct. But if you look at more human driven systems, then it is very possible for two XMPP clients to convey where they are and poke a hole for each other. Paul
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
