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

[David Yon <yon.ietf@rfdsoftware.com>]

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

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.


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

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


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