Subject: [IPsec] Issue #213/ #214 - Allow for non-direct end point connectivity

From: Vishwas Manral <[email-masked]>
Date: Fri, 11 May 2012 16:03:07 -0700

Hi,

Description: Direct endpoint-to-endpoint connectivity may not be possible.
Should gateways figure things out completely or just punt endpoints to a
closer gateway?

Detail Arguments: As Izaac and John Lesser pointed out this is more of a
routing issue. Though current solutions do not allow such connectivity
unless through a hub, I think from the security plane, we should not
preclude such connectivity. This could be achieved either transparently (no
IPsec component except the SPD involved), or by stitching tunnel traffic.

Suggested Resolutions: Specify explicitly that issues around direct
connectivity between endpoints are more of a Routing issue. However IPsec
should not prevent such a connectivity model.

Thanks,
Vishwas
=======================================================
Meeting notes:
                 # 213 In use case 2.1, direct endpoint-to-endpoint
connectivity
                  may not be possible
                          Need to mention challenges in use cases section
                          Paul: reminded that there will be a separate
requirement
                          section
                  # 214 Should gateways figure things out completely or
just punt
                  endpoints to a closer gateway?
                          Core gateway configuring is a solution, so
premature
                          Also in #213

---

From: Yoav Nir <[email-masked]>
Date: Sat, 12 May 2012 22:58:51 +0300

I'm not sure I understand the suggested resolution. The biggest barrier to direct connectivity is that the responder may be behind NAT. Is this considered a "routing issue"?  In any case, there are protocols for getting to a responder behind a NAT. They work well enough that VoIP solutions work pretty much everywhere where there isn't a firewall that's specifically targeting VoIP. I think we should user them, adapt therm or profile them for IKE/IPsec, although this does not necessarily belong in the solution document.

As for #214, I don't see how this is answered. If an gateway A would like to contact a host behind gateway Z, and does so through gateway B, must gateway B provide the addresses for gateway Z, or can it give the address of gateway D, which will then provide the address of gateway Z?  IOW, must redirection be 1-step?

Yoav

On May 12, 2012, at 2:03 AM, Vishwas Manral wrote:

> Hi,
> 
> Description: Direct endpoint-to-endpoint connectivity may not be possible. Should gateways figure things out completely or just punt endpoints to a closer gateway?
> 
> Detail Arguments: As Izaac and John Lesser pointed out this is more of a routing issue. Though current solutions do not allow such connectivity unless through a hub, I think from the security plane, we should not preclude such connectivity. This could be achieved either transparently (no IPsec component except the SPD involved), or by stitching tunnel traffic.
> 
> Suggested Resolutions: Specify explicitly that issues around direct connectivity between endpoints are more of a Routing issue. However IPsec should not prevent such a connectivity model.
> 
> Thanks,
> Vishwas
>                  # 213 In use case 2.1, direct endpoint-to-endpoint connectivity
>                   may not be possible
>                           Paul: reminded that there will be a separate requirement
>                           section
>                   # 214 Should gateways figure things out completely or just punt
>                           Core gateway configuring is a solution, so premature
>                           Also in #213
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Vishwas Manral <[email-masked]>
Date: Sat, 12 May 2012 13:20:44 -0700

Hi Yaov,

I do see NAT traversal as a requirement and should be made part of the
problem statement. I however do not see it as a resolution of #213 or #214.
I see resolution for #218 and #211 talk about NAT.

Routing is about how packet is sent to the nexthop closer to the
destination, which is what this issue is about in my view. It is what
determines if the destination and source are one hop away or can traverse
multiple gateways along the way. So if you only allow direct routing (or
through hubs), there is no way packets can traverse any other way.

What you seem to suggest is that there are ways in which VoIP can traverse
NAT at both the sender and the receiver. That in my view is a solution
suggestion, that you seem to be giving.

Can you give more details of what you mean by #214?

Thanks,
Vishwas

On Sat, May 12, 2012 at 12:58 PM, Yoav Nir <[email-masked]> wrote:

> I'm not sure I understand the suggested resolution. The biggest barrier to
> direct connectivity is that the responder may be behind NAT. Is this
> considered a "routing issue"?  In any case, there are protocols for getting
> to a responder behind a NAT. They work well enough that VoIP solutions work
> pretty much everywhere where there isn't a firewall that's specifically
> targeting VoIP. I think we should user them, adapt therm or profile them
> for IKE/IPsec, although this does not necessarily belong in the solution
> document.
>
> As for #214, I don't see how this is answered. If an gateway A would like
> to contact a host behind gateway Z, and does so through gateway B, must
> gateway B provide the addresses for gateway Z, or can it give the address
> of gateway D, which will then provide the address of gateway Z?  IOW, must
> redirection be 1-step?
>
> Yoav
>
> > Description: Direct endpoint-to-endpoint connectivity may not be
> possible. Should gateways figure things out completely or just punt

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 May 2012 00:14:18 +0300

On May 12, 2012, at 11:20 PM, Vishwas Manral wrote:

> Hi Yaov,
> 
> I do see NAT traversal as a requirement and should be made part of the problem statement. I however do not see it as a resolution of #213 or #214. I see resolution for #218 and #211 talk about NAT.
> 
> Routing is about how packet is sent to the nexthop closer to the destination, which is what this issue is about in my view. It is what determines if the destination and source are one hop away or can traverse multiple gateways along the way. So if you only allow direct routing (or through hubs), there is no way packets can traverse any other way.
> 
> What you seem to suggest is that there are ways in which VoIP can traverse NAT at both the sender and the receiver. That in my view is a solution suggestion, that you seem to be giving.
> 

#214 comes from a question that was raised. It assumes that part of the solution would be nodes that learn about the topology from other nodes.

The question was, is discovering the topology an iterative process, or a one-shot process. Suppose node A asks node B, but node B does not have the information (but knows where to get it). Does node B tell node A to go ask node C, or does it ask node C itself, and relay the answer to node A?

The text currently does not mandate one or the other.

Yoav

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 14 May 2012 14:56:49 -0700

Hi Yaov,

Thanks for the information.

What you seem to be talking about is iterative topology discovery, and not
data plane packet forwarding. I will try to clarify it further.

Thanks again,
Vishwas

On Mon, May 14, 2012 at 2:14 PM, Yoav Nir <[email-masked]> wrote:

> > What you seem to suggest is that there are ways in which VoIP can
> traverse NAT at both the sender and the receiver. That in my view is a
> solution suggestion, that you seem to be giving.
> >
> #214 comes from a question that was raised. It assumes that part of the
> solution would be nodes that learn about the topology from other nodes.
>
> The question was, is discovering the topology an iterative process, or a
> one-shot process. Suppose node A asks node B, but node B does not have the
> information (but knows where to get it). Does node B tell node A to go ask
> node C, or does it ask node C itself, and relay the answer to node A?
>