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: - 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.
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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
