Stewart Stremler wrote:
That is not precluded by NAT. It's only precluded for certian protocols
that made what turned out to be unwarranted assumptions.
I think part of the issue is that no one is explaining the issue
correctly. SIP isn't the problem.
SIP is just one of many protocols that really want to be able to connect
to "peers" in a client(ephemeral port)-client(ephemeral port)
arrangement rather than a client(ephemeral port)-server(static port)
arrangement.
Normally, I don't like to be quite this definitive, but, as someone who
has been playing quite a bit lately with punching through NAT devices,
you are just *wrong* about there being a reliable solution to this problem.
There is no reliable way from an application programming perspective to
reliably get two machines behind NAT devices to talk TCP to one another
on ephemeral ports. Even if both people *want* to. Even UDP is often
questionable.
If there is, *please* let me know how. I've got 2K lines of nasty code
that I would *love* to throw away.
Even the big boys haven't solved this problem and they have a *huge*
incentive with things like Xbox Live, Evercrack, World of Warcrack, etc.
Fortunately, most of the modern NAT devices are starting to do cone-type
translations. That still doesn't help TCP much (since you have to work
really hard to get to the SO_REUSEPORT flag), but at least UDP works
okay then.
What's wrong with passing port and IP numbers?
There is no way to autodiscover which ports are actually being used.
Multiple hosts behind the same NAT often want to use the same ports.
There is a reason why practically every TCP service uses ephemeral ports
on *outbound* connections. Are you saying that ephermeral ports should
be abandoned? If so, you disagree with the wisdom of decades of TCP
network programmers.
point the two end points have to know how to get ahold of each other. I
Yes. And that's a matter of policy. It should be UNDER THE CONTROL OF
THE USER.
Why? You, yourself, often point out that almost everything that winds
up under the control of the end user becomes a security hole.
Many users find NAT to be so annoying that they just give complete
control of the NAT to anyone via UPnP. Are you suggesting that is a
good solution? That is what your position tends to lead to.
If, however, there was a useful traversal protocol where I could at
least *request* a consistent routing and either be permitted or denied,
this mess would go away and security would improve. Upon denial, I
would quit trying to "penetrate" the NAT and flag to the user that he
was specifically *denied* by the NAT/firewall instead of wondering
whether it was just a crap firewall.
In fact, if I could request my external mapping, I could even cope with
"symmetric" NATs rather than just cone NATs. This would actually
improve security.
I think SIP/RTP are very well designed protocols which we will be seeing
I think they have one *obvious* flaw -- calling 'em "well-designed"
doesn't make that flaw go away. Especially when adding a couple of
bytes to each packet header makes the problem go away.
I fail to see how that solves the NAT traversal problem. I'd love to
hear the solution. Especially in the face of multiple users behind a NAT.
a lot more of in the near future. Currently people are getting around
the SIP/NAT thing by proxying all VOIP traffic. That is a nasty kludge
(such as is often inspired by NAT traversal solutions) which will not be
scalable, incurs a performance/call quality penalty, introduces more
points of failure,
Sounds like a protocol design failure to me.
Given that a whole lot of very smart people have taken a crack at this
problem and failed to solve it, your dismissal is a bit flippant. I'd
like to see your solution. STUN seems to be the best but is only weakly
supported; cone translation works with NATs that support it; other
people actually forge TCP packets to make this all work (NUTSS).
Of course, you're then up against the "not enough IPs" problem, so
nothing's really been accomplished. So blaming NAT is just a red
herring... the REAL whining is about how nobody wants to do IPv6.
Aside from the IPv6 geeks. :)
Blaming NAT is definitely not a red herring for the breakage of VOIP and
other protocols caused by NAT since ipv6 is not yet even involved in
most networks.
It is. The VOIP protocols that are broken by NAT are _broken_.
Sorry. You are wrong. I challenge you to create a VoIP protocol that
can directly connect two people behind symmetric NAT boxes (new external
port:IP for every external IP:external port: internal IP: internal port
quad). I'll even let you use a single colocated server as a rendezvous
host, but not to proxy all the traffic.
I await your solution.
Blame NAT is just a feeble excuse. We're at the point of foot-stomping
here, as accoriding to wikipedia, there are VoIP protocols that aren't
broken by NAT.
Only if they use a proxy.
Show me. Wikipedia is wrong.
It can be done, in principle. It has been done, in
practice. Therefore, the problem isn't NAT.
I have yet to see it. I await your reference. Seriously.
I don't see the advantage in designing a protocol that breaks with NAT,
or of demanding that people expose their internal networks to save on
having to use one of the other NAT-capable protocols. Put a port in
the protocol header already and it's an easy fix to make NAT boxen play
nice with it.
You quote this as a solution, but I don't see how that helps.
*Please* send me your solution and let me use it. I beg you.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
