Re: [MMUSIC] comedia-fix and the whole source address/port boondoggle

[Jonathan Rosenberg <jdrosen@dynamicsoft.com>]

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.



>     - 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.

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.

We should keep this bit separate from much of the rest of the 
comedia-fix stuff. I will comment on that separately (to a resolution I 
do think you will be happy with).

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic