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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 Feb 2003 22:54:10 -0500

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.

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

Still makes no sense to me.

Fact remains, that since you cannot know whether the source IP is 
accurate, it is simply unsafe to use.

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

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.

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

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.

-Jonathan R.

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

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: David Yon <[email-masked]>
Date: Tue, 04 Feb 2003 07:12:45 -0500

At 10:54 PM 2/3/2003, Jonathan Rosenberg wrote:
>>>purpose to prevent DOS attacks. I don't understand why you would not use 
>>>more tried-and-true mechanisms, such as return routability, which 
>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 
>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.

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

>from our esteemed chairs on whether this feature stays or goes.

Yes, indeed, I would also like to hear from the chairs on this.