Subject: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible

From: Stephen Hanna <[email-masked]>
Date: Tue, 20 Mar 2012 21:31:53 -0400

Another issue. Please comment on Suggested Resolution.

Thanks,

Steve

-----Original Message-----
From: ipsecme issue tracker [mailto:[email-masked]] 
Sent: Tuesday, March 20, 2012 6:58 PM
To: [email-masked]; [email-masked]
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/>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 21 Mar 2012 15:19:58 +0200

"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:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> IƧ��[�(^rC�{S�֥I�.�+r�^��

---

From: yogendra pal <[email-masked]>
Date: Thu, 22 Mar 2012 11:28:47 +0530

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 <[email-masked]> wrote:

> 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
>
> > To: [email-masked];
> [email-masked]
> > Ticket URL: <
> http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/213#comment:1>
> > IƧ��[�(^rC�{S�֥I�.�+r �^��
>

--

---

From: Yoav Nir <[email-masked]>
Date: Thu, 22 Mar 2012 09:30:35 +0200

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 <[email-masked]<mailto:[email-masked]>> wrote:
"direct endpoint-to-endpoint connectivity may not be possible if both endpoints are NATed"

Yoav

On Mar 21, 2012, at 3:31 AM, Stephen Hanna wrote:

> From: ipsecme issue tracker [mailto:[email-masked]<mailto:[email-masked]>]
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

--

---

From: yogendra pal <[email-masked]>
Date: Thu, 22 Mar 2012 21:55:34 +0530

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 <[email-masked]> 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:
> 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
>

---

From: Melinda Shore <[email-masked]>
Date: Thu, 22 Mar 2012 10:45:57 -0800

On 3/21/12 11:30 PM, Yoav Nir wrote:
> 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:

To be clear, NAT traversal mechanisms are not part of SIP, per se,
although they're frequently deployed in telephony environments.
The STUN mechanism was originally developed by some folks at ?Atari?
to support gaming, and STUN is not coupled to SIP - it can be
used by other protocols, as well.  That said, it's a pretty
ghastly protocols as protocols go, and provides no protections itself
against spoofed responses.  There's a dependence on peer authentication
by the application that invokes STUN, which is a pretty safe bet in
the VPN context and probably isn't a show-stopper even if it is a
little ill-making.

However, STUN is not the only approach (just the cheesiest).  midcom
and nsis provide the means to do direct requests between an endpoint
and a middlebox (NAT/firewall).  pcp is currently working on something
similar.  This is arguably a more robust, secure approach but it does
require support from the firewalls/NAT, not just the application.

Melinda

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Mar 2012 10:22:11 +0200

>>>>> "Yoav" == Yoav Nir <[email-masked]> writes:
    Yoav> "direct endpoint-to-endpoint connectivity may not be possible
    Yoav> if both endpoints are NATed" 

    Yoav> Why?  There are several protocols (SIP/RTP come to mind) that
    Yoav> manage endpoint-to-endpoint connectivity even when both are
    Yoav> behind NAT. Why shouldn't IPsec endpoints do this? 

yes, sorta.
1) lots of SIP things actually fail through NATs, even when the entire
   path is under VoIP/IP provider's control.  (For instance Busy-Light
   Indicators are sent async).  

2) SIP with STUN fails to using the STUN (or TURN) gateway to relay all traffic
   when it discovers a restricted-cone NAT.  That means that SIP "works"
   by sending all traffic to a "data centre" (DC to use the terms in
   this ticket)

I think that this issue needs enumerate the kinds of reasons why an
endpoint may be unable to receive connections.   In particular, we may
in fact have to detect the various situations and automatically work
around them.  (One work around is sometimes to have the captive node
initiate the connection, something that we have the control mechanisms
to do)