Notes by Mary Barnes and Andrew Zmolek, Edited by Dean Willis
Firewall Traversal adhoc- 1745-1900 (Thursday), Hilton Room 10,11,12 (chaired by Pete Cordell )
Secure "Legacy" Firewall/NAT Traversal for VoIP Products presentation by Pete Cordell
Agenda: Agree what we're doing See if there's support
Motivation: VoIP does not work thru plan firewalls and NATs. MIDCOM & Ipv6 will fix this o Both are still a little way off o Some people may not want to … …
Observations: There is a short term niche for solutions that allow VoIP traverse already deployed firewalls and NATs A number of proposals/implementations suggest there is a possible solution. There are multiple VoIP products: o Would be nice to have a single solution for all products (from a system administrator PoV).
Proposed Requirements: Enable VoIP thru an already deployed firewalls and NATs (no upgrade required to firewall). Must be protocol agnostic (work with SIP, MEGACO, H.323, MGCP…) Must be secure. Must keep control with the administrator. Must work will all flavours of NATs (full cone, symmetric, NAPT) Must allow existing clients/proxies, etc. unaware of the solution. o They may implement it directly if they wish. Discussion: Jonathan Rosenberg doesn't agree with that requirement (would only agree if he could do it in a secure manner).
Proposed requirements:
* Enable VoIP communication through already deployed firewalls and NATs
Protocol agnostic from the firewall's perspective>
* Must be secure (in the firewall sense) Control kept with administrator.
* Must work with all NAT/NAPT schemes (including cone, etc.)
* Must allow existing clients/proxies to be unaware of the solution
* Must be compatible with real-time media transport requirements
* Must not inhibit long-term solutions (midcom/IPv6)
* Must not break end-to-end security
New proposed requirements:
* Must not introduce new methods for a compromised entity (inside or outside)
to subvert the firewall
* Must be a tandemable solution (works between 2+ NATs)
* Must function under the consent (of the controlling parties?)
* Must understand or work with different topologies?
Proposed course of action:
* Agree on proposed charter
* Consensus that this is a problem worth solving
General Approach: Exploit existing firewall/NAT features where helpful Do not attempt to subvert firewall/NAT. Discussion: Jonathan Rosenberg: Is it a requirement that an outside entity cannot send pkts in (subvert)? Or better worded: This mechanism should not introduce any new mechanisms for outside entities to subvert the firewall. Need a new requirement that it must provide tandem support (i.e. from enterprise A to enterprise B).
Proposed Course of Action: Agree Requirements/Goals Agree on proposed charter Determine where we best fit in IETF Discussion: o Jonathan Rosenberg: already has agreement from ADs that this problem needs to be solved (intermediate solution) to avoid the BoF time issue. o Jonathan Rosenberg: agreed to follow-up (with Dave Oran) with the IESG and ADs on where this work should be done. Solicit candidate solutions. Come up with a single solution Standardize solution.
Conclusion: Propose and work thru solutions for an "Average Current Practice"
Pete expressed that this whole approach is to avoid people coming with their solution and trying to get it standardized - work thru the process. Pete suggested to use the IPFAN.org forum web site for the mailing list. However, there was disagreement with this and the suggestion was to put a new mailing list at IETF.org
Discussion then cycled back to a closing discussion on the requirements: New requirement: Only scenario whereby bearer should be triangle routed would be symmetrical NATs. ?What the scope of the problem to be solved? All protocols. Discussion centered around just UDP, just VoIP, just media??? Conclusion: Added a refined requirement to be UDP sessions that are set up by some other control path. Does the solution have to require updates to existing applications? Jonathan believes this is not possible without introducing security holes. When something else does the control, its problematic. Having the client do it, dramatically reduces the hole. Discussion of security issue: 2 cases: subverter remains in communication paths vs. subverter that opens pinhole and then disappears. Discussion of latency introduced by VPN tunnel proposal was argued. Response was that you have latency with the triangle routing …When you introduce elements that are topologically irrelevant to the media path will introduce latency. Dave Oran: If you're going to posit that you have an intermediary, then the problem is solved: Point to point VPN tunnel.
updated 13 Dec 2001 13:23:08 -0600