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 <y...@checkpoint.com> 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 > > 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 > > ======================================================= > > 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 > > > > _______________________________________________ > > 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
