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

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

At 10:54 PM 2/3/2003, Jonathan Rosenberg wrote:
> inline.
>
> David Yon wrote:
> > At 09:02 PM 1/14/2003, Jonathan Rosenberg wrote:
> > > 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".
> You simply dismiss my argument, but do not address it.
>
> My argument is, that when most users are behind NAT, the source IP of the 
> TCP connection won't match that in the SDP, and the net result is that 
> most if not all connections go in the low priority pool. This is 
> equivalent to no priority. I have also asserted that there are more 
> reliable, well-known techniques for DoS protection against these kinds of 
> attacks, which work better.
Well, one more try and then I'll agree to leave the topic where it is.

The piece of the puzzle you may be missing is that our system has the 
luxury of "owning" the front-line SIP proxies, and those proxies are 
outside of any client NAT boxes.  They can determine whether NATting is 
going on, and what the translation is FOR THE IP ADDRESS.  So if an INVITE 
is coming from an endpoint who's claiming a source address of 
192.168.0.128, but the INVITE message is sourced from the address 
216.153.163.173, it:

        (a) knows there's a NAT
        (b) knows with a high degree of certainty that the media
            will also appear to be sourced from 216.153.163.173.

It therefore rewrites the source address from 192.168.0.128 to 
216.153.163.173 for the downstream proxies (just like some poor tech at 
Netgear would have to do in their ALG :-)).  The vast majority of NAT's use 
a single public address, so this translation works.  Really.  We've seen 
it.  Existence proof hard at work.



> > > 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.
> 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.
While there's room for argument here, I'll just leave this for now.


> Anyway, this has remained a largely one-on-one discussion. I think all 
> that can be said has been said, on my part anyway. I would like to hear 
> from our esteemed chairs on whether this feature stays or goes.
Yes, indeed, I would also like to hear from the chairs on this.


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