Thanks Yoav for elaborating it. I was just thinking around this 3rd party broker to setup host-2-host tunnel. This broker can part of any private cloud or mixed cloud in Cloud network (Can be added to solution).
Stephen, To make p2p vpn scaleable, I think we should have simple solution with light weight implementation ( i.e. using minimal implementation of IKEv2 and IPsec). Do you think this SHOULD become the part of requirement. Thanks, Yogendra Pal Ericsson, India On Thu, Mar 22, 2012 at 1:00 PM, Yoav Nir <y...@checkpoint.com> wrote: > Sure. A VPN host (whether client or gateway) that is behind NAT is > generally unreachable from a random host. > > To allow random hosts to get there, the VPN host needs to "punch a hole" > in the NAT by sending a binding request to a STUN server. The IP routable > IP address and port that it uses should be stored somewhere, in case some > random VPN host wants to contact it. It has to be stored outside the VPN > host itself, because that host is unreachable. > > So if one or both of the VPN peers are behind NAT, we need some 3rd-party > or parties to broken the NAT traversal. We need: > - a STUN (or STUN-like) server for punching the hole > - storage for the discovered address and port > > In SIP these functions are done by the SBC. > > So just like the #214 and #217 issues, we need a 3rd party to broker the > host-2-host tunnel that we want to set up. It's tempting to assign this > function to a hub gateway as the VPN host already has the ability to > authenticate to it, but that should be part of the design, not the > requirements > > Yoav > > P.S: Sorry if my SIP/RTP terminology is off. It's all based on a cursory > reading of a Wikipedia article. > > On Mar 22, 2012, at 7:58 AM, yogendra pal wrote: > > I agree to what Yoav stated, that signalling part (SIP) and media part > (RTP) both SHOULD work even if there is NAT in the configuration today. > However, I could not get why we need to have new NAT traversal mechanism > using hub gateway, can you elaborate on this... > > Thanks and Regards, > Yogendra Pal > Ericsson, India > +91-9686202644 > > > On Wed, Mar 21, 2012 at 6:49 PM, Yoav Nir <y...@checkpoint.com> wrote: > >> "direct endpoint-to-endpoint connectivity may not be possible if both >> endpoints are NATed" >> >> Why? There are several protocols (SIP/RTP come to mind) that manage >> endpoint-to-endpoint connectivity even when both are behind NAT. Why >> shouldn't IPsec endpoints do this? >> >> If this requires some new NAT traversal mechanism, perhaps using a hub >> gateway in place of the SIP SBC, then this should be part of the >> requirements. >> >> This mechanism is needed even if only one endpoint is NATted, otherwise >> we're constraining who the initiator has to be. >> >> Yoav >> >> On Mar 21, 2012, at 3:31 AM, Stephen Hanna wrote: >> >> > Another issue. Please comment on Suggested Resolution. >> > >> > Thanks, >> > >> > Steve >> > >> > -----Original Message----- >> > From: ipsecme issue tracker [mailto:t...@tools.ietf.org] >> > Sent: Tuesday, March 20, 2012 6:58 PM >> > To: yaronf.i...@gmail.com; >> draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org >> > Subject: [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint >> connectivity may not be possible >> > >> > #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not >> be >> > possible >> > >> > In use case 2.1, direct endpoint-to-endpoint connectivity may not be >> possible >> > if both endpoints are NATed. >> > >> > Suggested Resolution: Mention this in section 2.1. >> > >> > -- >> > >> -------------------------+------------------------------------------------- >> > Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- >> > yaronf.ietf@… | problem@… >> > Type: defect | Status: new >> > Priority: normal | Milestone: >> > Component: p2p-vpn- | Severity: - >> > problem | Keywords: >> > Resolution: | >> > >> -------------------------+------------------------------------------------- >> > >> > Ticket URL: < >> http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/213#comment:1> >> > ipsecme <http://tools.ietf.org/ipsecme/> >> > >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> > IƧ��[�(^rC�{S�֥I�.�+r �^�� >> >> _______________________________________________ >> 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
