inline. David Yon wrote:
At 09:02 PM 1/14/2003, Jonathan Rosenberg wrote:Responses inline. David Yon wrote:comedia-fix again raises the argument against embedding the source address/port information in the SDP. That is something that I still feel strongly about, and work has progressed that makes use of it, although not as a fail-safe session correlation mechanism. We've found that it's useful as a DoS counter-measure, using the following design:
- An intermediate proxy on our network acts as a STUN-like
inverse-NAT translator to at least recover the likely address
from where the media will originate, and rewrites the SDP
if necessary.
It is quite a mystery to me how such a thing could possibly work in a causal fashion. The endpoint won't actually open any connections until after the offer/answer exchange has completed. The opening of the TCP connection is the thing which causes the NAT to assign a binding. So, the binding is assigned after the o/a exchange, but your proxy needs to know the binding before the exchange completes. So, I don't get it.
It works on ranking rather than absolute correlation.
Ranking?
You're correct about the NPAT port binding not being known ahead of time. However, most NPAT scenarios involve a single IP Address, so a media connection coming from that IP Address (regardless of source port) would be ranked higher than one that comes an unknown address.None of this makes sense to me. The problem remains that the proxy cannot know anything about the allocated nat binding until media is sent.
Still makes no sense to me.
And let's not forget about connections that originate from dial-up accounts (which accounts for the vast majority of home access), where the IP Address and port are actually correct, in which case the ranking is 100% accurate.
You simply dismiss my argument, but do not address it.- Our gateways, when under load, sort the incoming connection
pending queue based on source addresses that they expect
to arrive.
The idea is that when under DoS attack, connections sourced from uninvited addresses are not dealt with until the queue of invited addresses has been serviced. This is especially critical when the media is carried over TLS, and in our case we do not commence with the TLS handshake until either the connection has been correlated or until servicing the connection does not overload the gateway. The side-effect of a failed/incorrect inverse-NAT rewrite only occurs under heavy load, and is not fatal. But without the source address information, there is no way to implement such a scheme.
Since, practically speaking, I would expect the majority of users to connect to things from behind a NAT, this mechanism serves little purpose to prevent DOS attacks. I don't understand why you would not use more tried-and-true mechanisms, such as return routability, which validate a source IP address by sending it a cookie, and getting this cookie back. Such a mechanism actually works through NAT, and you can provide much more than just service prioritiziation based on it.
Again, the scheme as described works in the presence of NAT (despite assertions to the contrary), and allows the media to be 100% TLS without any out-of-spec "enhancements".
Because its unsafe. You have put a piece of information there, for which there is NO WAY to ever know whether it is reliable. Its not that it might be wrong, you don't know when its wrong and when its not. If I am building a proxy that wishes to look at the source IP in the SDP, and configure a pinhole in a firewall, instead of a cone, what advice can you give me about when I can use this source IP field? Your only answer is, you can only use it when you know its right because you control every piece of equipment on the network (the clients and all intervening nats). How can I be sure that this is the case? Someone all of a sudden installs a linksys and everything stops working, because the pinholes are not opened properly. That would be a fun customer call to get at 2 in the morning.I still maintain that, given we are painfully aware of the trials and tribulations of distributing source IP addresses in protocols, and given the vast potential for misuse, and the potentially small (if not ZERO) deployable benefits of this mechanism, I would like to see it removed. It is one thing to include a mechanism that is useful in many cases, but might not work in some (and then documenting such) as compared to a mechanism that will most likely be misused, and whose real benefit is small or zero.
It is OPTIONAL in the spec, and the limitations clearly outlined. At least one implementation finds it useful. I don't know how to be more clear than that, and why it causes such heartburn.